68 lines
2.8 KiB
Markdown
68 lines
2.8 KiB
Markdown
# 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 @.
|