Create LDM-2019-08-26.md
This commit is contained in:
parent
93cec651e3
commit
9e33b76fcd
1 changed files with 102 additions and 0 deletions
102
meetings/2019/LDM-2019-08-26.md
Normal file
102
meetings/2019/LDM-2019-08-26.md
Normal file
|
@ -0,0 +1,102 @@
|
||||||
|
# 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 seperately, 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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue