Repository navigation
[Version 9.0] Feature support for lambda discards - #1464
BillWagner wants to merge 4 commits into
Conversation
RexJaeschke
added
type: feature
BillWagner
added
the
meeting: discuss
|
@jskeet This is very small, and ready for a first look at our next meeting. |
jskeet
left a comment
jskeet
left a comment
There was a problem hiding this comment.
Remarkably simple - slightly odd, but I can see how it gets the desired effect.
BillWagner
removed
the
meeting: discuss
e94020b to
edf14c6
Compare
edf14c6 to
ec70e0c
Compare
ec70e0c to
577c911
Compare
|
An earlier version of this feature is already present on |
577c911 to
940a5dc
Compare
BillWagner
added
the
meeting: discuss
|
This is ready for a first review in our September meeting. |
Nigel-Ecma
left a comment
Nigel-Ecma
left a comment
There was a problem hiding this comment.
Some changes needed, otherwise looks OK (and an advert for why _ should no longer be allowed as a name, sometimes a breaking change is worth it, but yes this is MS… 😉)
| ### 12.21.2 Anonymous function signatures | ||
|
|
||
| The *anonymous_function_signature* of an anonymous function defines the names and optionally the types of the parameters for the anonymous function. The scope of the parameters of the anonymous function is the *anonymous_function_body* ([§7.7](basic-concepts.md#77-scopes)). Together with the parameter list (if given) the anonymous-method-body constitutes a declaration space ([§7.3](basic-concepts.md#73-declarations)). It is thus a compile-time error for the name of a parameter of the anonymous function to match the name of a local variable, local constant or parameter whose scope includes the *anonymous_method_expression* or *lambda_expression*. | ||
| If an *explicit_anonymous_function_parameter_list* or an *implicit_anonymous_function_parameter_list* contains multiple *identifier*s `_`, each of those identifiers denotes a discard ([§9.2.9.2](variables.md#9292-discards)). Otherwise, any single *identifier* `_` denotes a parameter. |
There was a problem hiding this comment.
This is not quite correct. It assumes that any identifiers in a explicit_anonymous_function_parameter_list/implicit_anonymous_function_parameter_list are parameter names, they could however be types. This needs to be written to restrict to the identifiers occurring directly in explicit_anonymous_function_parameter/implicit_anonymous_function_parameter.
A discard_token is a subset of identifier, so in both these cases the non-terminal is discard_token and referring to that is better than using _.
See also deconstructor_element where discard_token is explicitly included when other alternatives might also resolve to identifier, along with rules when to treat it as a discard or something else. This might help in deciding how this should be phrased.
jskeet
left a comment
jskeet
left a comment
There was a problem hiding this comment.
Agreed with Nigel's general comment too. It's pretty gnarly that the meaning changes between one and two occurrences...
| - The scope of a parameter declared in a *constructor_declaration* ([§15.11](classes.md#1511-instance-constructors)) is the *constructor_initializer* and *block* of that *constructor_declaration*. | ||
| - The scope of a parameter declared in a *lambda_expression* ([§12.21](expressions.md#1221-anonymous-function-expressions)) is the *lambda_expression_body* of that *lambda_expression*. | ||
| - The scope of a parameter declared in an *anonymous_method_expression* ([§12.21](expressions.md#1221-anonymous-function-expressions)) is the *block* of that *anonymous_method_expression*. | ||
| - With the exception of discard parameters (§12.21.2), the scope of a parameter declared in a *lambda_expression* ([§12.21](expressions.md#1221-anonymous-function-expressions)) is the *lambda_expression_body* of that *lambda_expression*. |
There was a problem hiding this comment.
Section 12.21.2 seems to split things into "discards" and "parameters" - in a way that suggests a discard isn't a parameter, making this change unnecessary. It might still be better for the sake of clarity, but we should probably decide that intentionally.
It's also worth noting that 12.21.2 just calls them discards, not discard parameters, at least sometimes.
Perhaps we should just change 12.21.2 to explicitly specify "non-discard parameters" rather than saying "otherwise they are parameters".
|
We think this is ready for @BillWagner to make the final changes before we get final approval and merge. |
ea8dc66 to
b6cad26
Compare
|
The language team has been talking approvingly of making a hard break in an upcoming version so |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 21570b74-c6f5-4fc5-ab6d-7546918d6ddb
Found a number of locations where discards should be mentioned in the context of lambda expressions or anonymous functions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 21570b74-c6f5-4fc5-ab6d-7546918d6ddb
Found some locations where "local variable" was used for a discard. That's now inaccurate, because a discard can be a lambda parameter. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 21570b74-c6f5-4fc5-ab6d-7546918d6ddb
b6cad26 to
1346b91
Compare
Update to address all feedback: - Count only identifiers directly naming parameters and use *discard_token*, so identifiers within parameter types aren’t counted. - Consistently distinguish discard parameters from non-discard parameters, including the related scope rules.
BillWagner
added
the
Review requested: Final approval
|
I've addressed the remaining comments. This should be ready to merge at the next meeting. |
BillWagner
added
meeting: priority
This replaces #995