-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Comments
No objection from me. |
This is closer to what @graydon originally had in mind with |
What about getting rid of the semi colons and just making
It's potentially a little unclear that This is doubly confusing because we also have move-mode and copy-mode parameters. What's the difference between |
@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
seems nicer than But I don't feel too strongly about this. |
I don't know that repeating |
Though if we do the nocopy stuff then I guess explicit |
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. |
Ok, I am happy with writing something like |
This is basically done, isn't it? |
yes, all done. (Except perhaps killing the old syntax) |
Currently, a capture clause is written:
I was thinking that maybe we should write it inline with the parameters, like so:
The reasons are (1) I find it easier to read but also (2) it integrates with the sugared closures better:
In general, then, the parameter list for a closure would have three parts:
move mode
capturescopy mode
capturesThe text was updated successfully, but these errors were encountered: