"Don't even mention I was here."
"I have lots of strong opinions, I'm just judicious with how I distribute them."
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.
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.
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.
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.
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.
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.
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.
We didn't quite get the code gen for this one finished up. Moving to 10.0 candidate.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This needs to be designed in concert with discriminated unions, so we'll move it to 10.0 Working Set.
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.
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.
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.
This will be part of the previously-mentioned forthcoming ref fields proposal. Move it to 10.0 Working Set.