9.8 KiB
C# Language Design Meeting for September 28th, 2020
Agenda
- Warning on
double.NaN - Triage
- Proposal: more improvements to nullable reference types
- Proposal: Required Properties
- Proposal: Extend with expression to anonymous type
- Proposal: Shebang (#!) Support
- Proposal: List Patterns
- Proposal: Add ability to declare global usings for namespaces, types and aliases by using a command line switch
- Proposal: "Closed" enum types
- Top-level functions
- Primary Constructors
- Champion: Simplified parameter null validation code
- Proposal: Support generics and generic type parameters in aliases
- Support for method parameter names in nameof
Quote of the day
- "On a rational basis I have nothing against this"
Discussion
Warning on double.NaN
https://github.com/dotnet/roslyn/issues/15936
We have an existing FxCop warning (CA2242) for invalid comparisons to double.NaN. We could consider bringing
that warning into the compiler itself as in a warning wave. However, as this analyzer is now shipped with the
.NET 5 SDK, is on by default, and deals more with API usage than with the language itself, it would also be fine
to leave it where it is.
Conclusion
Rejected. Leave the warning where it exists today.
Triage
Today, we got through half the remaining issues in the C# 10.0 Candidate milestone
Proposal: more improvements to nullable reference types
https://github.com/dotnet/csharplang/issues/3868
We have a few open topics in improvements to nullable reference types for the C# 10.0 timeframe. We're currently tracking LINQ improvements, Task-like type covariance, and uninitialized fields and constructors. This last point will likely be handled in conjunction with the proposals for required properties and initialization debt. The first two can be broken out to specific issues for the 10.0 timeframe.
Conclusion
File separate issues for the first two bullets, and triage into the 10.0 working set.
Proposal: Required Properties
https://github.com/dotnet/csharplang/issues/3630
We've already started talking about this one.
Conclusion
Triage into the 10.0 working set.
Proposal: Extend with expression to anonymous type
https://github.com/dotnet/csharplang/issues/3530
This proposal extends anonymous types to allow with expressions to change them, which we like a lot. In a way,
this extension makes anonymous types practically just anonymous record types, as they have the rest of the properties
of a record already: value equality, ToString, etc. It also fits in well with the idea of generally extending with
expressions to be more broadly applicable. Since anonymous types cannot be exposed as types in a public API, generating
new init members and the with clone method is a non-breaking change. New compilations can take advantage of the
features, and old compilations don't get affected by them.
As part of discussing this issue, we hit upon the idea of additionally allowing new { } to be target-typed. If a new
expression that did not have () is assigned to something that matches its shape (such as a record with the correct)
property names, we could just allow that new expression to be treated as the target-type constructor, rather than as
creating a new anonymous type. If the target-type is object or dynamic, it will still result in an anonymous object
being created, and there may be some tricks to figuring out generic inference, but we think it might be a path forward
towards making target-typed new more regular with the rest of the language (a complaint we have already heard). A future
proposal for that will be filed.
Conclusion
Triage into C# 10.0 working set for consideration with the rest of the with extensions.
Proposal: Shebang (#!) Support
https://github.com/dotnet/csharplang/issues/3507
While could eventually be an interesting proposal, the tooling is not there currently, and we feel the discussion around developer ergonomics in .NET 6 will shape our discussions in this area.
Conclusion
Triaged into X.0, and if the .NET tooling looks to add dotnet run csfile, we can consider again at that point.
Proposal: List Patterns
https://github.com/dotnet/csharplang/issues/3435
We like continuing to enhance the pattern support in C#, and are in general positive about this proposal. However, the
somewhat-fractured nature of .NET here works to our detriment, not just in the Count vs Length property names, but
in the general collection type sense. It would be nice to support IEnumerable, for example, which does not meet the
definitions set out in the proposal. Another consideration would be dictionary types: we don't have support for a
dictionary initializers specifically today, so having a decomposition step without a composition step would be odd, but
they would be a useful pattern nontheless. We also would like to see if we can find a way to make the syntax use braces
rather than square brackets to mirror collection initializers, though that will be difficult due to the empty property
pattern.
Conclusion
We'll spend design time on this in the C# 10 timeframe, though it may not make the 10.0 release itself. Triaged into the 10.0 working set.
Proposal: Add ability to declare global usings for namespaces, types and aliases by using a command line switch
https://github.com/dotnet/csharplang/issues/3428
This is, in many ways, a language-defining issue. The proposal itself is small, but it reflects the LDT's thinking of
future C# directions as a whole. It is also very divisive, both in the LDT and in the greater community, with a small
majority (both in the LDT and in the csharplang community) in favor of the feature. It introduces a level of magic to
the language that has been somewhat resisted in the past. Additionally, there is concern that there is no one set of
"base usings" that should be automatically included in files: a console app might only want to include System, while
an ASP.NET app might want to include a bunch of namespaces for various routing properties, controllers, and the like.
Conclusion
We'll discuss this more in the 10.0 timeframe. There could be interactions around the theme of developer QoL in the .NET 6 timeframe.
Proposal: "Closed" enum types
https://github.com/dotnet/csharplang/issues/3179
This proposal is linked to discriminated unions, in that it's a another type of closed hierarchy that C# does not support today.
Conclusion
Triage into 10.0 working set, to be discussed with DU's and closed type hierarchies in general.
Top-level functions
https://github.com/dotnet/csharplang/issues/3117
This is the follow-up work from C# 9 that we did not conclude in the initial push for top-level statements in C#,
namely in allowing globally-accessible functions in C# to float at the top level without a containing class. One
concern with generalizing this feature is that we have 20 years of BCL design that does not account for top-level
functions, in addition to other well-known and used libraries. For consistency, these libraries would likely not
use this new feature, which would relegate this feature to minimal usage. While many LDT members like the feature
in general, and would likely introduce it if we were redesigning C# from the ground up, we don't believe that the
feature belong in the C# we have today. We will continue to investigate whether top-level functions defined today
(which are local functions to the implicit Main method) should be callable from within the current file, in order
to have better compat with CSX. However, the overall feature is rejected.
Conclusion
Rejected.
Primary constructors
https://github.com/dotnet/csharplang/issues/2691
We have a proposal for this, and we are mostly in agreement that we should see this through.
Conclusion
Triage into 10.0 working set.
Champion: Simplified parameter null validation code
https://github.com/dotnet/csharplang/issues/2145
We have an implementation of this mostly ready. It was done in such as way as to be usable by the BCL, and will potentially save 7K+ lines of code there. Let's get it in.
Conclusion
Triage into 10.0 working set.
Proposal: Support generics and generic type parameters in aliases
https://github.com/dotnet/csharplang/issues/1239
We like the idea of improving aliases in general, and this could come into play when we talk about the previously-mentioned global usings. There are multiple possible flavors here though: there's simple aliases like we have today, that are freely convertible back to the underlying type, and then there are true opaque aliases that are not freely convertible back to the underlying type. Ideally, these latter aliases would be zero cost, which will likely require some work in conjunction with the runtime. Additionally, while we like the idea of making improvements here, we have a lot on the C# 10 plate currently, and think it would fit in better with the type enhancements we hope to make after 10.
Conclusion
Triaged into X.0.
Support for method parameter names in nameof
https://github.com/dotnet/csharplang/issues/373
We like this, and have the start of an implementation.
Conclusion
Triaged into 10.0 working set.