[Umbrella] Tuples Work Items

[jcouv]

This is the TODO list for the development of the tuples language feature for C# 7.

Known issues and scenarios

• VB tuples (LDM Visual Basic Language Design Meeting Notes - 2016.05.06 #11370)
  • Conversions (needs more testing)
  • Case sensitivity
  • Metadata import/export
  • Simple scenarios (parsing and binding for short tuples)
  • Type unification
  • Add support for long tuples
• Warning on tuple element name re-arrangement (Warnings missing on tuple name rearrangement #14217)
• Metadata roundtripping (Roundtrip tuple names through metadata #12347) (punted out of C#7.0, will need a warning wave)
• -(RC) Review proposed changes to public API
• -(RC) Review error messages
• Deconstruction ([Umbrella] Deconstruction work items #11299)
• Debugging (large)
• Making tuples available to early adopters (Roslyn Insider blockers)
  • Update issue
  • Gallery issue
  • Un-install issue
  • Telemetry
• IDE should help complete this code (int word, int) t = ($$word:$$ (fixed by Add a completion provider that suggests tuple names #16861)
• Validate proper interfaces (IEquatable, ...) (small)
• Validate extension methods (small)
• Perf validation
• Write spec
• Validate control/data flow
• Validate using tuple syntax in XML doc
• XML docs for public APIs
• Align terminology: "elements" (not "members" or "items" or "parts"), "cardinality" or "size" (but not "arity"), "tuple literal" (rather than "tuple expression" which could be ambiguous in speech).
• Resolve filed issues
• IOperations?
• Test ideas:
  • Verify that the Dynamic attribute is emitted on fields and signatures.
  • Compile the checked code from the ValueTuple library.
• Do we still need TupleElementNames property?
• Betterness with names/dynamic (we drop the names when conflicting) Implement dominant type inference for tuple types with mismatching element names #12585
• Report diagnostic for re-using member names out of position (LDM 5/20) (small) Implement dominant type inference for tuple types with mismatching element names #12585
• NoPia and tuples: If Pia tries to embed a TupleTypeSymbol, it should fail because the symbol says the type is not generic, but the underlying type is generic.
• Verify if various classes that deal with types need to handle TupleTypeSymbol. For example: TypeUnification, MemberRefMetadataDecoder, MemberSignatureComparer, SymbolMatcher (part of EnC).
• Support tuples with only some names (LDM 5/20)
• Add tuples to v7 flag (small)
• Tuple conversions (medium)
• Target typing
  • (byte, float) x = (1, 2) should work
  • return (null, null) should work in (object, object) M()
• Publish short-term nuget package for tuples library
• Get tuples library into corefx
• Test with patterns (shouldn't interfere)
• Update feature flag to new behavior (add diagnostics in syntax tree)
• Merge with underlying type
  • Retarget all members
  • VT same as (tuple)
  • Verify behavior for reserved member names
• Update well-known tuple types to TN naming convention
• Support tuples 8+
• Operators (unification surfaces operators from underlying type)
• Semantic info (members, declared symbols)
• Interop with System.Tuple

LDM

• Warning for name rearrangement? Warnings missing on tuple name rearrangement #14217
• Maybe no tuple name mismatch error when explicitly implementing interface? Should explicit interface implementations also report errors for tuple names mismatch? #12828
• Dynamic support: dynamic x = (a: 1, b: 2); Write(x.a);
• No var support in tuple types? (answer: no. LDM 7/13)

(byte y, var z) temp = (1, 2); // no var allowed in tuple type
(byte y, var z) = (1, 2); // but d-declaration with var is allowed

• Should the tuple library ship with ITuple interface? (answer: yes, let's work out the details with corefx team)
• Which reserved names to block.
• Explicit conversion issues (see LDM notes 6/17 for resolution)
• Names betterness (see LDM notes 6/17 for resolution)
• Better betterness for tuples (see LDM notes 6/17 for resolution)
• The distinction between tuple type and underlying type (if any, see proposal in Tuple Type vs Tuple Underlying Type in the Roslyn APIs #11382). (answer: the plan of record is to keep the distinction)
• Kevin Halverson's scenario (answer: yes, name rules were clarified in 5/20 meeting, including partially named tuple literals)

Corefx threads

• Copy implementation to mscorlib ([Umbrella] ValueTuple library work #13177)
• Create type forwarding assemblies pointing to mscorlib (this is not needed until some post-2.0 version of netstandard)
• Add reference from NetStandard2.0 meta-package (Add reference to ValueTuple package to NetStandard2.0 meta-package standard#22)
• Adding tuple-friendly LINQ APIS
• Conversion operators and deconstruct method for simple types (KVP PR was abandoned)
  • Identify tuple-like types
• ITuple implementation (Adding ITuple interface and implementation in ValueTuple corefx#10068)
  • ITuple should be in CompilerServices namespace.
  • Possibly with a different name.
  • Only in NetStandard 2.0 (so that Tuple and ValueTuple get them at the same time)
• Add some attributes to ValueTuple for debug info and intellisense completion
• Review TupleExtensions
• Rename attribute to naming convention: "Item" instead of "Element"
• Justify VT'0
• Add Deconstruct on ValueTuple (no, no need)
• Remove internal constraint from ValueTuple (no, we can leave)
• New attribute for names
• Publish library for ValueTuple
• Conversion methods and Deconstruct method for System.Tuple smaller than 21

Interaction with other language features:

• Test parsing backtracking/perf
• Test incremental parsing (probably un-affected)
• Test cannot assign from dynamic

General concerns:

• Error handling/recovery
  • Errors in parsing
  • Error handling for semantic errors (e.g. ambiguous lookup, inaccessible lookup, wrong kind of thing found, instance vs static thing found, wrong type for the context, value vs variable)
  • Missing types (mscorlib or others)
• Public interface of compiler APIs, backcompat scenarios
• backward and forward compatibility (i.e. interoperation with previous and future compilers, each in both directions)
• VB/F# interop, Mono issues
• BCL and other customer impact
• Determinism
• Loading from metadata (source vs. loaded from metadata)
• Atomicity
• Edit-and-continue
• Completeness of the specification as a guide for testing (e.g. is the spec complete enough to suggest what the compiler should do in each scenario?)
• Other external documentation
• Performance
• Reflection

Types and members:

• Access modifiers (public, protected, internal, protected internal, private), static modifier
• Parameter modifiers (ref, out, params)
• Attributes (including security attribute)
• Generics (type arguments, constraints, variance)
• default value
• partial classes
• literals
• enum (implicit vs. explicit underlying type)
• expression trees
• Iterators
• Initializers (object, collection, dictionary)
• array (single- or multi-dimensional, jagged, initilalizer)
• Expression-bodied methods/properties/...
• Extension methods
• Partial method
• Named and optional parameters
• String interpolation
• Properties (read-write, read-only, write-only, auto-property, expression-bodied)
• Interfaces (implicit vs. explicit interface member implementation)
• delegates
• Multi-declaration

Code:

• Operators (see Eric's list)
  • Operator overloading
• Lvalues: the synthesized fields are mutable
  • Ref / out parameters
  • Compound operators (+=, /=, etc ..)
  • Assignment exprs
• lambdas (capture of parameters or locals, target typing)
• execution order
• Target typing (var, lambdas, integrals)
• Type inference
• Conversions
  • Implicit (identity, implicit numeric, implicit enumeration, implicit nullable, null litaral, implicit reference, boxing, implicit dynamic, implicit constant, user-defined implicit conversion, anonymous function, method group)
  • Explicit (numeric, enumeration, nullable, reference, unboxing, dynamic, user-defined)
  • Anonymous functions
• nullable (wrapping, unwrapping)
• OHI
  • inheritance (virtual, override, abstract, new)
  • overload resolution
• Anonymous types
• Unsafe code
• LINQ
• constructors, properties, indexers, events, operators, and destructors.
• Async

Misc:

• reserved keywords (sometimes contextual)
• pre-processing directives
• COM interop

  Interaction with Debugger:

• typing in immediate/watch window (that also covers hovering over a variable)
• displaying locals (that also covers autos)

Interaction with IDE:

• Colorization
• Type ahead
• Intellisense (squiggles, dot completion)
• Renaming
• Interaction with incomplete code scenarios (e.g. while typing)
• More complete list: Discussion: IDE Test Plan for New Language Features #8389