3 KiB
C# Language Design Notes for Aug 26, 2019
Agenda
Triage of newly championed issues. Features that we may consider are placed in the milestone where we will look at them again. Listed here by target milestone.
Milestone 8.X
We are unsure if there will be an 8.1 release or we will go straight to C# 9.0. In the latter case we will triage this bucket and move things to 9.0 or later.
#883 Zero and one-element tuples
We don't have a good syntax for one-tuples.
But in deconstruction and pattern matching there is less of a syntax problem.
What does (3) mean? It is a constant 3. If you want a tuple literal, you can just give it a name - that is unambiguous. (_: 3) might become the common pattern, though _ isn't a discard for tuple element names.
Could consider splitting the feature and doing only one-element tuples in literals and deconstruction.
Milestone 9.0
This is the next major release (as C# 8.0 is a done deal at this point). Putting features in this milestone doesn't mean that we will do them here! It just means that we will consider them in this timeframe - possibly to be rejected or pushed out at that point.
#146
There's something to this, but instead of marking separately, we think it is paired with allowing nullary constructors on structs . For those we would warn on uses of default(S) that we can detect, similar to nullability.
#812
Could work with conjunctive patterns. An alternative would be a range-like syntax.
#1792, #1793, #1502
Let's keep ironing out annoying limitations in this space
#1881
Should think also of UTF8
For Memory<char> etc we would probably continue to require you to go through Span<char> etc.
#2585
Fits well with a "math" push, and should align with that.
Milestone X.0
These would be major features, and we don't expect to consider them for C# 9.0.
#339
This is a very fundamental feature, and we're not sure we have compelling scenarios. Possibly the next thing to look at after "type classes" in the advanced type features category.
#1047
This is probably in pattern matching's future somewhere, though we won't be ready for it in 9.0.
#538
Probably requires runtime work, and the scenarios don't currently justify that.
#2545 (Blocked)
We keep not moving on this. We'd need a good understanding with EF
Milestone X.X
These would be minor features which we don't expect to consider until after 9.0.
#2608
Fine, but doesn't rise to priority
Rejected
#301
This is subsumed by "extension everything" and the other proposals in that ilk. We do understand and support the scenario, but don't want the specific feature.
#1033
Rejected. The assignment should happen explicitly in the body, and the compiler can warn if you forget.
#1586
It shipped and it's in unsafe. We're ok with it.
#2383
The language is what it is at this point, and it is not worth doing work to "fix" it. However we should add a warning wave warning on the initializers saying they won't ever be called.