93 lines
2.5 KiB
Markdown
93 lines
2.5 KiB
Markdown
|
# C# Language Design Notes for Mar 19, 2018
|
||
|
|
||
|
***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
|
||
|
|
||
|
## Agenda
|
||
|
|
||
|
Triage
|
||
|
|
||
|
# 7.3
|
||
|
|
||
|
Moved undone 7.3 features to 8.0.
|
||
|
|
||
|
# Allow default in deconstruction
|
||
|
|
||
|
We allowed for `==`, so it seems we should also allow it for assignment and initialization.
|
||
|
|
||
|
Should probably not require `ValueTuple`, but that's more of a compiler thing.
|
||
|
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
The feature is a good idea. Even though it's simple, we should not rush it into 7.3. 8.0.
|
||
|
|
||
|
``` c#
|
||
|
case Customer { MiddleName: "" or null }
|
||
|
```
|
||
|
|
||
|
# and, or and not patterns 1350
|
||
|
`not` feels useful. `and` is hard to come up with scenarios for. `or` has more scenarios, but may be better served by a `in { 1, 2, 3 }` style pattern.
|
||
|
|
||
|
``` c#
|
||
|
if (x is not string s) { ... }
|
||
|
else { ... /* s */ }
|
||
|
```
|
||
|
|
||
|
`not` would cause definite assignment to "flip". Should `s` be disallowed in a `not` pattern.
|
||
|
|
||
|
The `{}` pattern for not null is a bit cryptic. `not null` would certainly be more direct.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
Punt to 8.x, when we know more of the rest of the pattern story.
|
||
|
|
||
|
|
||
|
# partial type inference #1349
|
||
|
|
||
|
We've talked about this many times in the past, but couldn't settle on a syntax that was nice enough and worth its while.
|
||
|
|
||
|
A 4th option: allow M<string>(...) to match an M with more type parameters. But that probably goes against intuition and would complicate overload resolution.
|
||
|
|
||
|
For 2: Just commas is known from typeof, so that concept is already in the language, though you can't mix "there" and "not there" today.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
8.X is when we'll look at it again.
|
||
|
|
||
|
|
||
|
# Permit `t is null` for unconstrained type parameter #1284
|
||
|
|
||
|
For null we special case type parameters in all other kinds of places, so this is the only place where you can't.
|
||
|
|
||
|
Also, `t is 3`. We allow *type* patterns, but not constant patterns.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
Absolutely should do this. Mark as 8.0.
|
||
|
|
||
|
|
||
|
# Implicitly scoped using #114 #1174
|
||
|
|
||
|
We have sympathy for this syntactic sugar, and we'd be interested in allowing it. It seems related to similar features, such as "defer" statements (avoids nesting `try/finally`).
|
||
|
|
||
|
Also fits nicely with the work we already did with expression variable scoping.
|
||
|
|
||
|
Also namespace without curlies, where you just say `namespace X.Y;` and it's in force for the remainder of the file.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
Discuss at 8.X. Could gewt pulled up to 8.0.
|
||
|
Let's also put defer and namespace into 8.X for consideration then.
|
||
|
|
||
|
# User-defined positional patterns
|
||
|
|
||
|
A next step from recursive patterns.
|
||
|
|
||
|
## Conclusion
|
||
|
|
||
|
Let's revisit in 8.X when recursive patterns have played out.
|
||
|
|
||
|
|
||
|
|
||
|
|