Closure reform

[nikomatsakis]

UPDATE:

This is a meta-bug now for tracking the work on completing closures. Now that #6801 has landed, the remaining pieces of work are:

• Issue Cleanup region hierarchy code, especially around closures #3696: Define region hierarchy for closures
• Issue proc bounds and closure lifetimes are parsed incorrectly #10553: We should not be accepting 'a || as syntax
• Issue support unboxed, uniquely typed closures #8622: Unboxed closures -- for the purposes of Closure reform #2202, just having a design and ensuring our treatment of closures is compatible with it is enough.
• Issue Calling a closure needs to be treated like a unique-immutable borrow #12224: Calling a closure is a kind of borrow.
• Issue Explain closures much better in the tutorial #13621: Explain closures much better in the tutorial

ORIGINAL FOLLOWS:
We need to revamp function types in light of regions. I think fn() (the "any" function) will go away, and fn@() and fn~() will be coercable to fn&(), just as with poiners/vectors/slices/etc. Also, fn&() becomes fn&r() (that is, r is a region), though the user won't typically need to write it. We can probably leave the representation as is, though we could also tweak fn&() to not have a ref count since there will be an explicit borrowing that occurs.

[catamorphism]

@nikomatsakis Should this be an RFC, since it would change syntax?

[nikomatsakis]

I don't feel it's necessary as I think it is more like a tweak. More importantly, I don't think that the work on regions makes much sense without taking these steps.

[nikomatsakis]

But I am happy to prepare an RFC if you think it makes sense.

[catamorphism]

Well, by the RFC process criteria, it is a change to the AST that isn't just refactoring, doesn't relate to numerical criteria, and would be noticed by end users. But if you think that would be overkill, it's your call.

[nikomatsakis]

OK. FWIW I don't think it'd be noticed by end-users: that is, all existing syntax will remain valid, it'll just be re-interpreted to be regions-based.

[catamorphism]

I'm confused -- you said in the original post that "fn() (the "any" function) will go away"? So isn't that making existing syntax not valid anymore? (Not trying to be antagonistic here, I just don't understand.)

[nikomatsakis]

You're right, what I wrote was misleading (or perhaps just plain wrong). I meant that it would go away in the type system. You'd still be able to type fn(), it'd just be omitting the region bound (region bounds can always be omitted in all cases where they appear, such as slices etc).

[catamorphism]

Ah ok. Then I agree, not really visible to users, hence no need for an RFC.

[catamorphism]

Moved to 0.4.

[nikomatsakis]

@catamorphism I think the beginning work here has been done. The remaining work is probably better left to 0.5. Is there some specific change you had in mind for 0.4?

[catamorphism]

@pcwalton was saying that borrowing an @fn to a &fn results in a memory leak, and that that had something to do with this bug.

[nikomatsakis]

That is true. I am not sure that we need to fix that for 0.4 though.