# C# Language Design Meeting for September 28th, 2020

## Agenda

1. [Warning on `double.NaN`](#warning-on-double.nan)
2. [Triage](#triage)
    1. [Proposal: more improvements to nullable reference types](#proposal-more-improvements-to-nullable-reference-types)
    2. [Proposal: Required Properties](#proposal-required-properties)
    3. [Proposal: Extend with expression to anonymous type](#proposal-extend-with-expression-to-anonymous-type)
    4. [Proposal: Shebang (#!) Support](#proposal-shebang--support)
    5. [Proposal: List Patterns](#proposal-list-patterns)
    6. [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)
    7. [Proposal: "Closed" enum types](#proposal-closed-enum-types)
    8. [Top-level functions](#top-level-functions)
    9. [Primary Constructors](#primary-constructors)
    10. [Champion: Simplified parameter null validation code](#champion-simplified-parameter-null-validation-code)
    11. [Proposal: Support generics and generic type parameters in aliases](#proposal-support-generics-and-generic-type-parameters-in-aliases)
    12. [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.
