Conversation
Fixes dotnet#1155 This PR follows the process outlined in dotnet#1155 (comment)
|
Carried over from #1159:
This PR is for that rethink… |
|
@Nigel-Ecma If a tuple expression doesn't have a type, then I think we don't get to the part where
Thus a tuple expression is only evaluated when it has a type, and thus a tuple expression can be evaluated by constructing the corresponding |
| A tuple expression is evaluated by evaluating each of its element expressions in order from left to right. | ||
|
|
||
| A tuple value can be obtained from a tuple expression by converting it to a tuple type ([§10.2.13](conversions.md#10213-implicit-tuple-conversions)), by reclassifying it as a value ([§12.2.2](expressions.md#1222-values-of-expressions))) or by making it the target of a deconstructing assignment ([§12.21.2](expressions.md#12212-simple-assignment)). | ||
| A tuple value is obtained from a tuple expression by evaluating it and storing the result in corresponding `System.ValueTuple<...>` type, and initializing each of its fields in order from left to right by evaluating the corresponding tuple element expression of `E`, converting it to the corresponding element type of `T` using the implicit conversion found, and initializing the field with the result. |
There was a problem hiding this comment.
System.ValueTuple isn't mentioned anywhere else in this file. Shouldn't we be a bit more specific? There are wrinkles in how tuples map to the ValueTuple types. For instance, a tuple type (T1, T2, T3, T4, T5, T6, T7, T8) must be represented as nested ValueTuples, because the TRest type argument of a tuple must always itself be a nested tuple: ValueTuple<T1, T2, T3, T4, T5, T6, T7, ValueTuple<T8>>
There was a problem hiding this comment.
I see that conversions.md does mention ValueTuple<...> a few times, but it doesn't explain the required recursive encoding.
There was a problem hiding this comment.
I vaguely remember that we discussed how far we needed to go with that encoding aspect.
If we can avoid referring to ValueTuple<...> in this section, it's likely to make our lives easier... even if it means doing a bit more work in 8.3.11 to effectively make that the only place that needs to go into that detail. If we can say "logically there's a type with N fields" then we can make this line (in expressions.md) simpler.
| ### 12.2.2 Values of expressions | ||
|
|
||
| Most of the constructs that involve an expression ultimately require the expression to denote a ***value***. In such cases, if the actual expression denotes a namespace, a type, a method group, or nothing, a compile-time error occurs. However, if the expression denotes a property access, an indexer access, or a variable, the value of the property, indexer, or variable is implicitly substituted: | ||
| Most of the constructs that involve an expression ultimately require the expression to denote a ***value***. In such cases, if the actual expression denotes a namespace, a type, a method group, or nothing, a compile-time error occurs. However, if the expression denotes a property access, an indexer access, a tuple, or a variable, the value of the property, indexer, tuple, or variable is implicitly substituted: |
There was a problem hiding this comment.
Why do we mention tuple expressions here, but we don't mention other kinds of expressions such as object creation expressions, array creation expressions, lambda expressions, and so on?
| ### 10.2.13 Implicit tuple conversions | ||
|
|
||
| An implicit conversion exists from a tuple expression `E` to a tuple type `T` if `E` has the same arity as `T` and an implicit conversion exists from each element in `E` to the corresponding element type in `T`. The conversion is performed by creating an instance of `T`’s corresponding `System.ValueTuple<...>` type, and initializing each of its fields in order from left to right by evaluating the corresponding tuple element expression of `E`, converting it to the corresponding element type of `T` using the implicit conversion found, and initializing the field with the result. | ||
| An implicit conversion exists from an expression `E` with a tuple type `S` to a tuple type `T` if `S` has the same arity as `T` and an implicit conversion exists from each element type in `S` to the corresponding element type in `T`. |
There was a problem hiding this comment.
I think I'm following, but just checking. Is there a tuple type S for every tuple expression? For instance, does (default, default) have a tuple type S in:
(object, object) x = (default, default);
|
@Nigel-Ecma is working on a new PR - he will close this when opening the new one. |
4 participants
Fixes #1155
This PR follows the process outlined in #1155 (comment)
This replaces the first commit in #1159.
See #1359 (review) for the status of this PR.