# 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:

``` c#
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".

``` c#
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)`

``` c#
(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

``` c#
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

``` c#
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`?

``` c#
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 @.