Repository navigation
Closure reform #2202
Description
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.
Activity
catamorphism commentedon Apr 19, 2012
@nikomatsakis Should this be an RFC, since it would change syntax?
nikomatsakis commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
But I am happy to prepare an RFC if you think it makes sense.
catamorphism commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
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 commentedon Apr 19, 2012
Ah ok. Then I agree, not really visible to users, hence no need for an RFC.
catamorphism commentedon Oct 1, 2012
Moved to 0.4.
nikomatsakis commentedon Oct 1, 2012
@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 commentedon Oct 1, 2012
@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 commentedon Oct 2, 2012
That is true. I am not sure that we need to fix that for 0.4 though.
Cleanup how we handle proto in types, remove unsound subtyping
Cleanup how we handle proto in types, remove unsound subtyping
13 remaining items
nikomatsakis commentedon Sep 26, 2013
Update: I have a branch that does a lot of the borowck work. Semi-blocked on fixing destructor semantics.
brson commentedon Oct 8, 2013
Current plan of action:
fnpnkfelix commentedon Nov 29, 2013
cc me
nikomatsakis commentedon Jan 16, 2014
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 commentedon Feb 12, 2014
Updated main comment.
flaper87 commentedon Apr 19, 2014
updated the description to add #13621
pcwalton commentedon Jun 9, 2014
I propose closing this as an outdated metabug that is currently not particularly actionable. We have several other bugs for unboxed closures.
pnkfelix commentedon Jun 12, 2014
Closing in favor of new unboxed closures approach we are now adopting: see rust-lang/rfcs#114
Auto merge of rust-lang#2202 - InfRandomness:infrandomness/rustdoc-fi…
Allow users to select a subset of harness to run (rust-lang#2202)
Merge pull request rust-lang#2202 from Kobzol/pull-ci
Merge pull request rust-lang#2202 from bjorn3/intrinsic_test_lockfile