-
Notifications
You must be signed in to change notification settings - Fork 86
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
C# 7.x: out Variables #44
Conversation
60806a1
to
e066350
Compare
standard/expressions.md
Outdated
@@ -541,7 +541,7 @@ argument_name | |||
argument_value | |||
: expression | |||
| 'ref' variable_reference | |||
| 'out' variable_reference | |||
| 'out' local_variable_type? identifier |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The speclets for out vars and deconstructions relied on declaration_expression
.
But in this doc, I see 'out' local_variable_type? identifier
and in the deconstruction draft I see tuple_deconstruction_expression
.
I'm not sure what is the benefit of this structure.
I think having a declaration_expression
that appears in multiple contexts is a good factorization. Then we don't need new syntax for deconstructions (it's declaration_expression
and tuple_expression
).
Tagging @cston since I'll be away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more context on syntax shape (was discussed with LDM): #285
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use declaration_expression
.
Tagging @Nigel-Ecma for grammar checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
declaration_expression is different and cannot simply be substituted in this location. Here local_variable_type is optional, it is not in declaration_expression. I'll find the change and add a suggestion there…
3dbd7fd
to
1f55d4c
Compare
1f55d4c
to
02f89c6
Compare
Part of adding V7.3 support for out variables in extra places.
This text has been moved to PR 596.
Some of this text has been moved to PR 596
- Overhauled argument list text - Added better conversion text - Removed discards-in-assignment text
93a8bee
to
91d0247
Compare
5066217
to
fb0efd8
Compare
2ee4c22
to
9aace93
Compare
@jskeet This one is now ready for the upcoming meeting. Latest edits:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't done a full review just looked at the grammar change as requested – unfortunately the change was wrong so needs reverting, suggestion in comment.
standard/expressions.md
Outdated
@@ -1033,6 +1081,8 @@ Given an implicit conversion `C₁` that converts from an expression `E` to a ty | |||
- `E` exactly matches both or neither of `T₁` and `T₂`, and `T₁` is a better conversion target than `T₂` ([§12.6.4.6](expressions.md#12646-better-conversion-target)) | |||
- `E` is a method group ([§12.2](expressions.md#122-expression-classifications)), `T₁` is compatible ([§20.4](delegates.md#204-delegate-compatibility)) with the single best method from the method group for conversion `C₁`, and `T₂` is not compatible with the single best method from the method group for conversion `C₂` | |||
|
|||
The conversion from an implicitly-typed out variable declaration is not considered better than any other conversion from expression. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I know what this means, it doesn't feel terribly clear - maybe we just need a reference to the "conversion from expression" section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not sure it adds anything. Should this paragraph be removed? For discussion.
@@ -6051,7 +6101,7 @@ assignment_operator | |||
|
|||
The left operand of an assignment shall be an expression classified as a variable, a property access, an indexer access, an event access or a tuple. A declaration expression is not directly permitted as a left operand, but may occur as a step in the evaluation of a deconstructing assignment. | |||
|
|||
The `=` operator is called the ***simple assignment operator***. It assigns the value or values of the right operand to the variable, property, indexer element or tuple elements given by the left operand. The left operand of the simple assignment operator shall not be an event access (except as described in [§15.8.2](classes.md#1582-field-like-events)). The simple assignment operator is described in [§12.21.2](expressions.md#12212-simple-assignment). | |||
The `=` operator is called the ***simple assignment operator***. When the left operand is not a discard (§9.2.8.1), this operator assigns the value of the right operand to the variable, property, or indexer element given by the left operand. Otherwise, the right operand is evaluated with its value going unused. The left operand of the simple assignment operator shall not be an event access (except as described in [§15.8.2](classes.md#1582-field-like-events)). The simple assignment operator is described in [§12.21.2](expressions.md#12212-simple-assignment). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this change and the next one intended to be in this PR? It's not really about out
parameters... was it just something else that should have been in a discards PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. This PR in its original form included both discards and out parameters. I left this change in place because it wasn't in the updated discards and tuples PR.
Let's discuss at the meeting if it should be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Action from 2023-04-19: @BillWagner to remove from this PR, but add it to the issue that @MadsTorgersen has already created for polishing on discards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some simple final changes, then let's merge.
@@ -6051,7 +6101,7 @@ assignment_operator | |||
|
|||
The left operand of an assignment shall be an expression classified as a variable, a property access, an indexer access, an event access or a tuple. A declaration expression is not directly permitted as a left operand, but may occur as a step in the evaluation of a deconstructing assignment. | |||
|
|||
The `=` operator is called the ***simple assignment operator***. It assigns the value or values of the right operand to the variable, property, indexer element or tuple elements given by the left operand. The left operand of the simple assignment operator shall not be an event access (except as described in [§15.8.2](classes.md#1582-field-like-events)). The simple assignment operator is described in [§12.21.2](expressions.md#12212-simple-assignment). | |||
The `=` operator is called the ***simple assignment operator***. When the left operand is not a discard (§9.2.8.1), this operator assigns the value of the right operand to the variable, property, or indexer element given by the left operand. Otherwise, the right operand is evaluated with its value going unused. The left operand of the simple assignment operator shall not be an event access (except as described in [§15.8.2](classes.md#1582-field-like-events)). The simple assignment operator is described in [§12.21.2](expressions.md#12212-simple-assignment). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Action from 2023-04-19: @BillWagner to remove from this PR, but add it to the issue that @MadsTorgersen has already created for polishing on discards.
Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]>
To the best of my analysis, this PR is fully replaced by #664. |
Closing as obsolete. |
The handling of discards in tuple deconstruction and pattern matching is deferred to the PRs that add support for tuples and pattern matching, respectively. This PR only handles the out parameter and assignment scenarios.
A couple of
> TODO
placeholders will need attention once those other PRs are created.