191 lines
9.7 KiB
Markdown
191 lines
9.7 KiB
Markdown
# C# Language Design Meeting for September 9th, 2020
|
|
|
|
## Agenda
|
|
|
|
1. [Triage issues still in C# 9.0 candidate](#triage-issues-still-in-C#-9.0-candidate)
|
|
2. [Triage issues in C# 10.0 candidate](#Triage-issues-in-C#-10.0-candidate)
|
|
|
|
# Quote(s) of the Day
|
|
|
|
"Don't even mention I was here."
|
|
|
|
"I have lots of strong opinions, I'm just judicious with how I distribute them."
|
|
|
|
# Discussion
|
|
|
|
## Triage issues still in C# 9.0 candidate
|
|
|
|
To start, we updated https://github.com/dotnet/csharplang/blob/master/Language-Version-History.md with the features that have been merged into the compiler for C# 9 at
|
|
this point, and moved their corresponding issues to the [9.0 milestone](https://github.com/dotnet/csharplang/milestone/18).
|
|
|
|
### Null propagation expression does not allow `!` as a nested operator form
|
|
|
|
https://github.com/dotnet/csharplang/issues/3393
|
|
|
|
We did not adequately prioritize this given the urgency of the breaking change. We need to attempt to get this into C# 9 or we may end up being stuck with this behavior
|
|
given that the nullable rollout period is ending, or we'd need to consider taking what could be a large breaking change. We'll attempt to throw and catch this hail mary,
|
|
and it will stay in C# 9.0 candidate for now.
|
|
|
|
### [Proposal] Improve overload resolution for delegate compatibility
|
|
|
|
https://github.com/dotnet/csharplang/issues/3277
|
|
|
|
We had hoped to get this done as a refactoring while implementing function pointers, but did not end up getting it in. This is a good candidate for community contribution
|
|
as it can be implemented and tested in a single PR, so we'll move this to any time.
|
|
|
|
### Interface static method, properties and event should ignore variance
|
|
|
|
https://github.com/dotnet/csharplang/issues/3275
|
|
|
|
This is implemented, just waiting on infrastructure to move forward to a runtime where it can be tested. Will be in C# 9 as soon as that happens, and is staying in 9.0
|
|
candidate.
|
|
|
|
### Records-related issues
|
|
|
|
https://github.com/dotnet/csharplang/issues/3226
|
|
https://github.com/dotnet/csharplang/issues/3213
|
|
https://github.com/dotnet/csharplang/issues/3137
|
|
|
|
These are all records related issues. We didn't get all of what we want to accomplish in this space in C# 9, so we need to break the still-to-be-done parts of these
|
|
proposals out into separate issues for 10 or later and close/move these.
|
|
|
|
### Primary Constructors
|
|
|
|
https://github.com/dotnet/csharplang/issues/2691
|
|
|
|
We didn't managed to break this out of records in a satisfactory manner for 9, but we would like to get this in for 10. Retriaged to 10.0 Candidate.
|
|
|
|
### Proposal: Target typed null coalescing (`??`) expression
|
|
|
|
https://github.com/dotnet/csharplang/issues/2473
|
|
|
|
When attempting to spec and implement this, we found that it doesn't actually work well in practice, as `??` has a number of complicated rules around type resolution
|
|
already and what part should be target-typed is confusing. We believe that, given the investigation, we won't be moving this one forward, and it moves to the Likely
|
|
Never milestone.
|
|
|
|
### Champion: Simplified parameter null validation code
|
|
|
|
https://github.com/dotnet/csharplang/issues/2145
|
|
|
|
We didn't quite get the code gen for this one finished up. Moving to 10.0 candidate.
|
|
|
|
### Champion: relax ordering constraints around `ref` and `partial` modifiers on type declarations
|
|
|
|
https://github.com/dotnet/csharplang/issues/946
|
|
|
|
We had put this in 9.0 because we thought it would be required for `data` classes. That did not end up being the case, and we don't have high priority for it otherwise.
|
|
We'd accept a contribution if a community member wanted to loosen the restriction, thus moved to Any Time.
|
|
|
|
### Champion "Nullable-enhanced common type"
|
|
|
|
https://github.com/dotnet/csharplang/issues/33
|
|
https://github.com/dotnet/csharplang/issues/881
|
|
|
|
We said when doing additional target-typing work that we either had to do these now, or it would be very complicated to implement later without avoiding breaking changes.
|
|
Given that the target-typing we added more generally addresses this in most scenarios, we don't believe that the additional "break glass in case of emergency" bar is
|
|
met with these, and they are moved to Likely Never.
|
|
|
|
### Proposal: improvements to nullable reference types
|
|
|
|
https://github.com/dotnet/csharplang/issues/3297
|
|
|
|
This is part of the ongoing nullable improvements list. We will split the parts that have not been implemented out into a separate list, and then move this to 9.0 with
|
|
just the things actually implemented for this release.
|
|
|
|
## Triage issues in C# 10.0 candidate
|
|
|
|
We will be moving issues from the 10.0 candidate bucket to the 10.0 Working Set bucket during triage. Issues in the 10.0 Working Set bucket are issues that we have decided
|
|
to devote some design time towards during the upcoming 10.0 timeframe, but not all of the issues triaged into this working set will actually make it into the 10.0 release.
|
|
|
|
### Proposal: Exponentiation operator
|
|
|
|
https://github.com/dotnet/csharplang/issues/2585
|
|
|
|
We don't feel that this is a major priority for the language currently. It is a relatively small amount of work, however. If a community member wants to add a proposal
|
|
for a specific symbol to use for the operator and a precedence for that symbol, we'd be happy to consider it at that point. Moved to Any Time.
|
|
|
|
### Champion "Type Classes (aka Concepts, Structural Generic Constraints)"
|
|
|
|
https://github.com/dotnet/csharplang/issues/110
|
|
|
|
We feel that issues in improving the type system, such as type classes, roles, statics in interfaces, etc, are the next big area of investment for the language. While
|
|
we may not end up seeing the results of these investments in the 10.0 timeframe, we need to start designing them now or we'll never see them at all. As such, we are
|
|
labeling this issue as "Long lead" to indicate that there is a lot of design work to come before and implementation can even start to happen. Moved to 10.0 Working Set.
|
|
|
|
### generic constraint: where T : ref struct
|
|
|
|
https://github.com/dotnet/csharplang/issues/1148
|
|
|
|
This is related to a forthcoming proposal on ref fields, as well as to the aforementioned type system improvements we want to make. To really be useful beyond allowing
|
|
`Span<Span<T>>`, ref structs need to be able to implement interfaces, and so this will be considered in tandem with them. Moved to 10.0 Working Set.
|
|
|
|
### Champion "CallerArgumentExpression"
|
|
|
|
https://github.com/dotnet/csharplang/issues/287
|
|
|
|
While this could be considered Any Time, we already have most of an implementation and would like to get it in for C# 10, so we are moving it to 10.0 Working Set.
|
|
|
|
### Champion "Allow Generic Attributes"
|
|
|
|
https://github.com/dotnet/csharplang/issues/124
|
|
|
|
A community member is contributing this feature, and while we don't think there is any design work left to do from the language side there's still a bit of work on the
|
|
implementation itself. We'll move this to 10.0 Working Set, as opposed to Any Time, to ensure that we give priority if there does end up being any language work to do.
|
|
|
|
### C# Feature Request: Allow value tuple deconstruction with default keyword
|
|
|
|
https://github.com/dotnet/csharplang/issues/1358
|
|
|
|
This is a small quality of life change that we already have a PR for. Let's get it merged, and move this issue to 10.0 Working Set.
|
|
|
|
### Expression Blocks/Switch Expression and Statement Enhancements
|
|
|
|
https://github.com/dotnet/csharplang/issues/3086
|
|
https://github.com/dotnet/csharplang/issues/3038
|
|
https://github.com/dotnet/csharplang/issues/3087
|
|
https://github.com/dotnet/csharplang/issues/2632
|
|
|
|
We know that we want to make some improvements here. We need to narrow down on a concrete proposal as we have a lot of different scopes/syntaxes currently, and then we
|
|
can proceed with implementation. Move to 10.0 Working Set.
|
|
|
|
### Champion: Name lookup for simple name when target type known
|
|
|
|
https://github.com/dotnet/csharplang/issues/2926
|
|
|
|
We consider this a somewhat essential necessary feature for discriminated unions, so this should be considered in concert with that. Move to 10.0 Working Set.
|
|
|
|
### Proposal: "Closed" type hierarchies
|
|
|
|
https://github.com/dotnet/csharplang/issues/485
|
|
|
|
This needs to be designed in concert with discriminated unions, so we'll move it to 10.0 Working Set.
|
|
|
|
### Championed: Target-typed implicit array creation expression `new[]`
|
|
|
|
https://github.com/dotnet/csharplang/issues/2701
|
|
|
|
This needs some design work around either making it a generalized feature for type parameter-based inference or if it specializes for the interfaces that array implements
|
|
specifically. We don't feel that this particularly pressing, so we're moving it to X.0 unless we hear a need to add it to align with other .NET priorities.
|
|
|
|
### Champion: `base(T)` phase two
|
|
|
|
https://github.com/dotnet/csharplang/issues/2337
|
|
|
|
While this was part of the initial feature set for DIMs, we don't hear any particular customer complaints for this feature. We'll move it to X.0 until such time as we
|
|
hear customer asks for it.
|
|
|
|
### Champion "defer statement"
|
|
|
|
https://github.com/dotnet/csharplang/issues/1398
|
|
|
|
LDM was somewhat negative on this feature. There are times when you'd want to pair code to run at the end of a block/method return, but defer has invisible consequences
|
|
here because it would have to use try/finally. This give defer a penalty that would prevent it from being used in many of the places we'd otherwise want to use it ourselves.
|
|
Additionally, there is significant negative community sentiment about this feature, much more than we usually get for participation on any particular csharplang issue. As a
|
|
result, we are moving this feature to Likely Never, and if we see similar significant outcry to the rejection we can reconsider this.
|
|
|
|
### Five ideas for improving working with fixed buffers
|
|
|
|
https://github.com/dotnet/csharplang/issues/1502
|
|
|
|
This will be part of the previously-mentioned forthcoming ref fields proposal. Move it to 10.0 Working Set.
|