C# Language Design Notes for Jul 12, 2016

Agenda

Several design details pertaining to tuples and deconstruction resolved.

All or nothing with element names?

There's certainly a case for partial names on literals - sometimes you want to specify the names of some of the elements for clarity. These names have to fit names in the tuple type that the literal is being converted to:

List<(string firstName, string lastName, bool paid)> people = ...;

people.Add(("John", "Doe", paid: true));

Do we also want to allow partial names in types?

Yes we do. We don't have strong arguments against it, and generality calls for it. It's likely that there are scenarios, and not allowing will feel arbitrary. "The bool deserves a clarifying name, but the TypeSymbol is clear".

var t = (1, y: 2); // infers (int, int y)
(int x, int) t = (1, 2);

As a reminder, we distinguish between leaving out the name and explicitly specifying Item1, Item2, etc. You get a warning if you use Item1... in literals if they are not explicitly there in the target type. (Warning)`

(int, int) t = (Item1: 1, Item2: 2); // Warning, names are lost

For the editor experience we imagine offering completion of a named element in the corresponding position of a tuple literal.

ITuple

interface ITuple
{
    int Size;
    object this[int i] { get; }
}

ITuple is really an interface for dynamically checking for deconstructability. Whether we should add ITuple now depends on whether we think we want to allow recursive patterns to do that, once we add them.

We do think we want that.

We cannot use an existing collection interface (such as IReadOnlyCollection) because we want to be able to distinguish between deconstructable objects and collections (which might one day get their own pattern). It is fine for a class to implement both.

ValueTuple<...> should of course implement ITuple, and the translation of long tuples should work.

The Framework team should chime in on the specific shape and names on the interface. Is ITuple the right name, or is it too narrow? Is IDeconstructable more to the point or is it too long? Should it be Size or Length or Count?

var when var type exists

class var {}
var (x, y) = e;

People use this trick to block the use of var, and we should let them, even though we disagree with the practice. So even though a type isn't valid in that position, we will let the presence of a var type turn this into an error.

var method

What if there's a method called var?

ref int var(int x, int y);
var(x, y) = e; // deconstruction or call?

Here there is no prior art, so we will always interpret the var to mean a deconstructing declaration. If you wanted the method call, parenthesize the call or use @.

2.8 KiB Raw Blame History