-
Notifications
You must be signed in to change notification settings - Fork 1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added notes for September 28th, 2020
- Loading branch information
Showing
2 changed files
with
214 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,207 @@ | ||
# C# Language Design Meeting for September 28th, 2020 | ||
|
||
## Agenda | ||
|
||
1. [Warning on `double.NaN`](#warning-on-double.nan) | ||
2. [Triage](#triage) | ||
a. [Proposal: more improvements to nullable reference types](#proposal-more-improvements-to-nullable-reference-types) | ||
b. [Proposal: Required Properties](#Proposal-Required-Properties) | ||
c. [Proposal: Extend with expression to anonymous type](#Proposal-Extend-with-expression-to-anonymous-type) | ||
d. [Proposal: Shebang (#!) Support](#Proposal-Shebang-(#!)-Support) | ||
e. [Proposal: List Patterns](#Proposal:-List-Patterns) | ||
f. [Proposal: Add ability to declare global usings for namespaces, types and aliases by using a command line switch](#Proposal:-Add-ability-to-declare-global-usings-for-namespaces,-types-and-aliases-by-using-a-command-line-switch) | ||
g. [Proposal: "Closed" enum types](#Proposal:-"Closed"-enum-types) | ||
h. [Top-level functions](#Top-level-functions) | ||
i. [Primary Constructors](#Primary-Constructors) | ||
j. [Champion: Simplified parameter null validation code](#Champion:-Simplified-parameter-null-validation-code) | ||
k. [Proposal: Support generics and generic type parameters in aliases](#Proposal:-Support-generics-and-generic-type-parameters-in-aliases) | ||
l. [Support for method parameter names in nameof()](#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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters