Skip to content

Implement syntax for anonymous unboxed closures #14449

New issue

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

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

Already on GitHub? # to your account

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-type-system Area: 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
bors pushed a commit to rust-lang-ci/rust that referenced this issue Apr 22, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-type-system Area: 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