Tuple and underlying type unification. Part 3. #11136
Conversation
- Added support for properties and events in tuple type symbol. - Made additional adjustments to implementation of tuple symbol display around presence of element names.
|
test prtest/lin/dbg/unit32 please http://dotnet-ci.cloudapp.net/job/roslyn_prtest_lin_dbg_unit32/6872/ |
| @@ -349,7 +349,7 @@ private BoundExpression CreateTupleConversion(CSharpSyntaxNode syntax, BoundTupl | |||
| var destTupleType = (TupleTypeSymbol)targetType; | |||
| // do not lose the original element names in the literal if different from names in the target | |||
|
|
|||
| // PROTOTYPE(tuples): Come back to this, what about locations? | |||
| // Come back to this, what about locations? (https://github.com/dotnet/roslyn/issues/11013) | |||
There was a problem hiding this comment.
Yes, we should keep the locations of the original tuple type
|
LGTM |
| if (CanUseTupleTypeName(symbol)) | ||
| // If top level tuple uses non-default names, there is no way to preserve them | ||
| // unless we use tuple syntax for the type. So, we give them priority. | ||
| if (HasNonDefaultTupleElementNames(symbol) || CanUseTupleTypeName(symbol)) |
There was a problem hiding this comment.
Should we consider a textual representation of the underlying type with names too? Maybe System.ValueTuple<int a, int b>?
There was a problem hiding this comment.
That would violate the language grammar as it is defined today. Besides, the case when both the top level and the nested levels have friendly names cannot originate from source. So, I think it is fine to drop some information in this case.
In reply to: 62353540 [](ancestors = 62353540)
|
Looks good to me, but I don't really understand why we care to expose properties and events from the underlying type. It doesn't seem strictly required for the tuples feature. LGTM |
|
@AlekseyTs @VSadov @jcouv |
@VSadov, @jcouv, @dotnet/roslyn-compiler Please review.