Skip to content

RFC: Integrate capture clause into parameter list #2096

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
nikomatsakis opened this issue Apr 1, 2012 · 11 comments
Closed

RFC: Integrate capture clause into parameter list #2096

nikomatsakis opened this issue Apr 1, 2012 · 11 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@nikomatsakis
Copy link
Contributor

Currently, a capture clause is written:

fn@[move x, y; copy z](a: T) { ... }

I was thinking that maybe we should write it inline with the parameters, like so:

fn@(a: T; move x, y; copy z) { ... }

The reasons are (1) I find it easier to read but also (2) it integrates with the sugared closures better:

task::spawn {|move x, y; copy z|
    ...
}

In general, then, the parameter list for a closure would have three parts:

  • the normal parameters
  • the move mode captures
  • the copy mode captures
@marijnh
Copy link
Contributor

marijnh commented Apr 1, 2012

No objection from me.

@pcwalton
Copy link
Contributor

pcwalton commented Apr 1, 2012

This is closer to what @graydon originally had in mind with bind. Sounds good to me.

@brson
Copy link
Contributor

brson commented Apr 1, 2012

What about getting rid of the semi colons and just making move and copy indicate a captured argument, like

fn&(a: int, b: int, copy c: int) as opposed to fn&(a: int, b: int; copy c)

It's potentially a little unclear that copy means capture, but you have that same confusion with the semi-colon syntax if there are only captures: fn&(copy c). So I don't think the semi-colon accomplishes much.

This is doubly confusing because we also have move-mode and copy-mode parameters. What's the difference between fn&(-c) and fn&(move c). It's not obvious.

@nikomatsakis
Copy link
Contributor Author

@brson there is no need to list the types for parameters that are copied or moved. I thought about removing the semi-colons so that there are no "sections" in the parameter list. the main downside is the need to repeat the move keyword a lot. It seems like it might be common to want to copy and move a number of variables, in which case I think:

fn@(a: int, b: int;
    move x, y;
    copy w, z)

seems nicer than fn@(a: int, b: int, move x, move y, copy w, copy z).

But I don't feel too strongly about this.

@brson
Copy link
Contributor

brson commented Apr 6, 2012

I don't know that repeating move is a big deal. I hope that using capture clauses at all is very rare. Usually the last move pass just does the right thing I think.

@brson
Copy link
Contributor

brson commented Apr 6, 2012

Though if we do the nocopy stuff then I guess explicit copy captures would be more common.

@catamorphism
Copy link
Contributor

No objections from me. I like @brson 's suggestion beginning with "What about getting rid of the semi colons and just making move and copy indicate a captured argument?" I don't think the semicolon would be very enlightening to me if I didn't understand what it meant already. It's not a huge deal to me, though.

@nikomatsakis
Copy link
Contributor Author

Ok, I am happy with writing something like fn foo(..., move x, copy y, move z).

@pcwalton
Copy link
Contributor

pcwalton commented Jun 9, 2012

This is basically done, isn't it?

@pcwalton
Copy link
Contributor

pcwalton commented Jun 9, 2012

cc @nikomatsakis

@nikomatsakis
Copy link
Contributor Author

yes, all done. (Except perhaps killing the old syntax)

Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants