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.

[brendanzab]

A possible test:

// http://www.paulgraham.com/accgen.html

fn accgen<T:Copy + Num>(n: &a/mut T) -> @a/fn(T) -> T {
    fn@(i: T) -> T { *n += i; *n }
}

fn main() {
    let mut n = 0;
    let f = accgen(&mut n);
    // Should print "1, 2, 3"
    io::println(fmt!("%?, %?, %?", f(1), f(1), f(1)));
}

fn@(...) certainly looks odd. I'm guessing you were forced into that syntax? ie. @fn(...) was for deprecated functionality?

[nikomatsakis]

Not critical for 0.6; removing milestone

[nikomatsakis]

What remains to be done:

• define closure hierarchy more precisely (Cleanup region hierarchy code, especially around closures #3696)
• custom closure kind bounds (needed by Dynamically sized types #6308) (UPDATE: Custom closure (and trait) "kind" bounds #3569)
• change how region bounds are associated with closures and add tests (related to Dynamically sized types #6308)

[nikomatsakis]

Oh, I forgot to add the biggest instance of work yet to be done. Making them sound! See this blog post for details:

http://smallcultfollowing.com/babysteps/blog/2013/04/30/the-case-of-the-recurring-closure/

This is blocked on #6298.

[nikomatsakis]

Repurposing this issue as a metabug.

[metajack]

nominating backwards compat

[graydon]

accepted for backwards-compatible milestone

[graydon]

accepted for backwards-compatible milestone

[metajack]

visiting for triage. nothing to add.

[nikomatsakis]

Update: I have a branch that does a lot of the borowck work. Semi-blocked on fixing destructor semantics.

[brson]

Current plan of action:

• make ~fn once fns
• rename &fn to |A| -> B
• rename extern "Rust" to fn
• rename ~fn -> proc
• replace various do &fn use cases with RAII
• remove do for &fn
• add capture clauses??
• note: procs should carry file/line info for debugging?

[pnkfelix]

cc me

[nikomatsakis]

As part of this work, we need to update the kinds for function types to take into account the mutability etc of the captured values.

[nikomatsakis]

Updated main comment.

[flaper87]

updated the description to add #13621

[pcwalton]

I propose closing this as an outdated metabug that is currently not particularly actionable. We have several other bugs for unboxed closures.

[pnkfelix]

Closing in favor of new unboxed closures approach we are now adopting: see rust-lang/rfcs#114