149 lines
5.8 KiB
Markdown
149 lines
5.8 KiB
Markdown
# C# Language Design Notes for Feb 21, 2017
|
|
|
|
## Agenda
|
|
|
|
We triaged some of the [championed features](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3A%22Proposal+champion%22), to give them a tentative milestone and ensure they had a champion.
|
|
|
|
As part of this we revisited potential 7.1 features and pushed several out.
|
|
|
|
1. Implicit interface implementation in Visual Basic *(VB 16)*
|
|
2. Delegate and enum constraints *(C# X.X)*
|
|
3. Generic attributes *(C# X.0 if even practical)*
|
|
4. Replace/original *(C# X.0 if and when relevant)*
|
|
5. Bestest betterness *(C# 7.X)*
|
|
6. Null-coalescing assignments and awaits *(C# 7.X)*
|
|
7. Deconstruction in from and let clauses *(C# 7.X)*
|
|
8. Target-typed `new` expressions *(C# 7.X)*
|
|
9. Mixing fresh and existing variables in deconstruction *(C# 7.1)*
|
|
10. Implementing `==` and `!=` on tuple types *(C# 7.X)*
|
|
11. Declarations in embedded statements *(No)*
|
|
12. Field targeted attributes on auto-properties *(C# 7.1)*
|
|
|
|
|
|
# Implicit interface implementation in Visual Basic
|
|
[Champion "Implicit interface implementation"](https://github.com/dotnet/vblang/issues/38)
|
|
|
|
This long-requested feature in VB would also help deal with problems related to [default implementations of interface members](https://github.com/dotnet/csharplang/issues/52).
|
|
|
|
## Conclusion
|
|
Candidate for VB 16.
|
|
|
|
|
|
# Delegate and enum constraints
|
|
[Champion "Generic constraint `delegate` (or allow `System.Delegate` as a constraint)"](https://github.com/dotnet/csharplang/issues/103)
|
|
|
|
[Champion "Generic constraint `enum` (or allow `System.Enum` as a constraint)"](https://github.com/dotnet/csharplang/issues/104)
|
|
|
|
This is a common request. Could
|
|
|
|
- semantically require an actual delegate/enum or just allow the base class
|
|
- syntactically show up as either the base class or the keyword
|
|
|
|
For delegates we need to consider how to deal with `MulticastDelegate`.
|
|
|
|
## Conclusion
|
|
Candidates for a minor C# version.
|
|
|
|
|
|
# Generic attributes
|
|
[Champion "Allow Generic Attributes"](https://github.com/dotnet/csharplang/issues/124)
|
|
|
|
Even though this would work in principle, there are bugs in most versions of the runtime so that it wouldn't work correctly (it was never exercised).
|
|
|
|
We need a mechanism to understand which target runtime it works on. We need that for many things, and are currently looking at that. Until then, we can't take it.
|
|
|
|
## Conclusion
|
|
Candidate for a major C# version, if we can make a sufficient number of runtime versions deal with it.
|
|
|
|
|
|
# Replace/original
|
|
[Champion "Replace/original and code generation extensions"](https://github.com/dotnet/csharplang/issues/107)
|
|
|
|
If there's renewed investment in source generators, we'll add this, but this is not driven from the language end.
|
|
|
|
## Conclusion
|
|
Candidate for a major C# version, if and when source generators or similar efforts take place.
|
|
|
|
|
|
# Bestest betterness
|
|
[Champion "Bestest Betterness"](https://github.com/dotnet/csharplang/issues/98)
|
|
|
|
We want to do it, but not low-hanging enough for C# 7.1 time frame.
|
|
|
|
## Conclusion
|
|
Candidate for a minor C# release in the 7.X wave.
|
|
|
|
|
|
# Null-coalescing assignments and awaits
|
|
[Champion "Null-coalescing assignments"](https://github.com/dotnet/csharplang/issues/34)
|
|
|
|
[Champion "Null-conditional await"](https://github.com/dotnet/csharplang/issues/35)
|
|
|
|
These need a little more design work and general bake time than what 7.1 allows.
|
|
|
|
`await?` is an odd kind of keyword, but changing `await` to not throw on null may also be an issue. Thought needed.
|
|
|
|
## Conclusion
|
|
Candidate for a minor C# release in the 7.X wave.
|
|
|
|
|
|
# Deconstruction in from and let clauses
|
|
[Champion "deconstruction in from and let"](https://github.com/dotnet/csharplang/issues/189)
|
|
|
|
Too many worms in the can for 7.1.
|
|
|
|
## Conclusion
|
|
Candidate for a minor C# release in the 7.X wave.
|
|
|
|
|
|
# Target-typed `new` expressions
|
|
[Champion "Target-typed `new` expression"](https://github.com/dotnet/csharplang/issues/100)
|
|
|
|
Links well with target typed `default` expressions, but too much design and potential fallout for 7.1. Interaction with anonymous objects as well.
|
|
|
|
## Conclusion
|
|
Candidate for a minor C# release in the 7.X wave.
|
|
|
|
|
|
# Mixing fresh and existing variables in deconstruction
|
|
[Champion "Mix Declarations and Variables in Deconstruction"](https://github.com/dotnet/csharplang/issues/125)
|
|
|
|
This rounds out the C# 7.0 experience, and was a late design change we didn't get to implementing.
|
|
|
|
May lead to occasional confusion, as in `M((int x, y) = e)` (declaring `y`)? We are OK with that.
|
|
|
|
## Conclusion
|
|
Candidate for C# 7.1.
|
|
|
|
|
|
# Implementing `==` and `!=` on tuple types
|
|
[Champion "Support for == and != on tuple types"](https://github.com/dotnet/csharplang/issues/190)
|
|
|
|
There's design work. It's not just call `.Equals` recursively.
|
|
|
|
`==` today works between int and byte, for instance. We should probably make `(i1, i2) == (b1, b2)` work with that same equality.
|
|
|
|
Also for generics, for a type parameter `T` and a `t` of that type, we should allow `(t, i) == (null, 0)` by recursively applying the special "compare to null" semantics of equality over type parameters of C# today.
|
|
|
|
Too big for 7.1.
|
|
|
|
## Conclusion
|
|
Candidate for a minor C# release in the 7.X wave.
|
|
|
|
|
|
# Declarations in embedded statements
|
|
|
|
Now that you can declare expression variables in an embedded statement, it's odd that old-fashioned declaration statements are forbidden in an embedded position (such as an if-branch, for instance). However, now that you can use a discard instead of a dummy variable declaration, the motivating scenario also goes away.
|
|
|
|
## Conclusion
|
|
Let's not do it.
|
|
|
|
|
|
# Field targeted attributes on auto-properties
|
|
[Champion "Auto-Implemented Property Field-Targeted Attributes"](https://github.com/dotnet/csharplang/issues/42)
|
|
|
|
Technically a breaking change, since the field target is already permitted today, but ignored. We don't expect anyone to be relying on this, though!
|
|
|
|
## Conclusion
|
|
Candidate for 7.1.
|