meetings/2019/LDM-2019-08-26.md
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.
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.
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.
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.
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.
Could work with conjunctive patterns. An alternative would be a range-like syntax.
Let's keep ironing out annoying limitations in this space
Should think also of UTF8
For Memory<char> etc we would probably continue to require you to go through Span<char> etc.
Fits well with a "math" push, and should align with that.
These would be major features, and we don't expect to consider them for C# 9.0.
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.
This is probably in pattern matching's future somewhere, though we won't be ready for it in 9.0.
Probably requires runtime work, and the scenarios don't currently justify that.
We keep not moving on this. We'd need a good understanding with EF
These would be minor features which we don't expect to consider until after 9.0.
Fine, but doesn't rise to priority
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.
Rejected. The assignment should happen explicitly in the body, and the compiler can warn if you forget.
It shipped and it's in unsafe. We're ok with it.
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.