Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement syntax for anonymous unboxed closures #14449

Closed
pcwalton opened this issue May 27, 2014 · 7 comments · Fixed by #16122
Closed

Implement syntax for anonymous unboxed closures #14449

pcwalton opened this issue May 27, 2014 · 7 comments · Fixed by #16122
Labels
A-typesystem Area: The type system B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-enhancement Category: An issue proposing an enhancement or a PR with one.
Milestone

Comments

@pcwalton
Copy link
Contributor

This is part of unboxed closures. cc @nikomatsakis

I suggest that we adopt the following syntax for now. We can change it and bikeshed it later.

|&: x, y| x + y // Fn
|&mut: x, y| x + y // FnMut (the commonest, eventually the default)
|: x, y| x + y // FnOnce

These create anonymous struct types that move their upvars (cf. #12831) and implement the Fn/FnMut/FnOnce traits.

Per discussion last week I believe that this is necessary for 1.0. Nominating for backcompat-lang because we will remove the old closures after this is done.

@brson brson added this to the 1.0 milestone May 29, 2014
@brson
Copy link
Contributor

brson commented May 29, 2014

1.0 backcompat lang, but please get an RFC approved.

@pcwalton
Copy link
Contributor Author

This is nearly done. Once Fn and FnOnce are implemented, and some better test coverage for the entire end-to-end feature (both cross-crate and intra-crate) is in, I'll close this.

@brson
Copy link
Contributor

brson commented Jul 30, 2014

Tracking rust-lang/rfcs#114

pcwalton added a commit to pcwalton/rust that referenced this issue Aug 14, 2014
This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.

This breaks code that looked like:

    let mut f;
    {
        let x = &5i;
        f = |&mut:| *x + 10;
    }

Change this code to avoid having a reference escape. For example:

    {
        let x = &5i;
        let mut f; // <-- move here to avoid dangling reference
        f = |&mut:| *x + 10;
    }

I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.

Closes rust-lang#14449.

[breaking-change]
bors added a commit that referenced this issue Aug 14, 2014
…=pnkfelix

This patch primarily does two things: (1) it prevents lifetimes from
leaking out of unboxed closures; (2) it allows unboxed closure type
notation, call notation, and construction notation to construct closures
matching any of the three traits.

This breaks code that looked like:

    let mut f;
    {
        let x = &5i;
        f = |&mut:| *x + 10;
    }

Change this code to avoid having a reference escape. For example:

    {
        let x = &5i;
        let mut f; // <-- move here to avoid dangling reference
        f = |&mut:| *x + 10;
    }

I believe this is enough to consider unboxed closures essentially
implemented. Further issues (for example, higher-rank lifetimes) should
be filed as followups.

Closes #14449.

[breaking-change]

r? @pnkfelix
@alexchandel
Copy link

Does this mean unboxed closures are done? Because the guide still has procs. The guide could also explain ref |...| expr vs |...| expr, and |&mut: ...| expr vs |: a, b, c| expr.

@huonw
Copy link
Member

huonw commented Oct 25, 2014

@alexchandel unboxed closures have a lot of bugs, and, as with everything Rust-y, migration is not done instantly, it takes time and energy.

(The docs/guide are dependent on the stdlib being switched.)

@ftxqxd
Copy link
Contributor

ftxqxd commented Oct 25, 2014

Also, given that the strategy for this has changed, and the |&: foo| -> bar| syntax is no more, should this issue be reopened? The new syntax has not been implemented yet for unboxed closure expressions; only the trait sugar has been implemented (and only for trait bounds, too).

@nixpulvis
Copy link

Also unifying the syntax in the RFCs might be a really good idea soon.

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
fix: Recover from `pub()` visibility modifier
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants