94 lines
2.6 KiB
Markdown
94 lines
2.6 KiB
Markdown
|
# C# Language Design Notes for Oct 18, 2017
|
||
|
|
||
|
***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
|
||
|
|
||
|
|
||
|
## Agenda
|
||
|
|
||
|
|
||
|
# 189
|
||
|
|
||
|
``` c#
|
||
|
from s in strings
|
||
|
let (b, i) = (int.TryParse(s, out var x), x)
|
||
|
where b
|
||
|
select i
|
||
|
```
|
||
|
|
||
|
Problem is that out vars also aren't yet allowed.
|
||
|
|
||
|
We don't allow declaration expressions in
|
||
|
|
||
|
1. queries
|
||
|
2. constructor initializers
|
||
|
3. field/property initializers
|
||
|
|
||
|
All of these were because we didn't settle the scope question. Time to do that.
|
||
|
|
||
|
Let's put these as issues. And let's put those issues as 7.3. And let's put this one as 7.3.
|
||
|
|
||
|
|
||
|
# 100
|
||
|
|
||
|
The difficulty of this depends on the level of ambition. It has to play in to applicability of overloads this is passed to. If we allow member initializers, then we need to bind those
|
||
|
|
||
|
``` c#
|
||
|
M(new { X = 7, Y = new { A = "Hello" } });
|
||
|
|
||
|
x = new () { Y = { e1, e2 } };
|
||
|
```
|
||
|
|
||
|
If we're lucky, this is just about whether the conversion exists or not.
|
||
|
|
||
|
Would there be a way that this would even influence generic type inference?
|
||
|
|
||
|
``` c#
|
||
|
M(() => new (1));
|
||
|
```
|
||
|
|
||
|
We'd need to think about this.
|
||
|
|
||
|
It may be that there's a subset of the feature that's simpler. We would need that subset to not preclude going further later.
|
||
|
|
||
|
Spooky action at a distance
|
||
|
|
||
|
``` c#
|
||
|
M(Foo)
|
||
|
M(Goo)
|
||
|
|
||
|
M(new (1))
|
||
|
```
|
||
|
|
||
|
Goo has a constructor that takes an int. Adding such a constructor to Foo will break the code.
|
||
|
|
||
|
Now, adding a constructor is equivalent to adding a conversion in terms of the breaks it can entail.
|
||
|
|
||
|
May also need more betterness rules.
|
||
|
|
||
|
|
||
|
It could be that it's better to limit the feature so it does not participate in type inference and betterness, and can always be checked as a conversion. It might even be worth considering it only specifically to where one target type is known (so no overload applicability).
|
||
|
|
||
|
|
||
|
For now, let's put it in 8.0. We don't believe it's going to make 7.3, but that makes us still consider it for design time.
|
||
|
|
||
|
|
||
|
# 179
|
||
|
|
||
|
For people who care about perf, they already need 3 or 4 overloads, and this would be yet another overload peopple will yell at them to add.
|
||
|
|
||
|
For no parameters today, you no longer need an overload to avoid allocation, because we now use `Array.Empty`.
|
||
|
|
||
|
`params IEnumerable<T>` would be even less performant than the array one, because enumeration allocates.
|
||
|
|
||
|
The point of it more is that if I want to take an `IEnumerable<T>` anyway, then it's a convenience to add params and take the arguments individually.
|
||
|
|
||
|
|
||
|
Not important enough to prioritize time for the design soon. Let's make this X.X.
|
||
|
|
||
|
|
||
|
# How to continue
|
||
|
|
||
|
Scan 7.X for remaining 7.3 items and ignore the rest for a bit.
|
||
|
|
||
|
|