csharplang/meetings/2021/LDM-2021-09-15.md

C# Language Design Meeting for September 15th, 2021

Agenda

• Feedback from the C# standardization committee
• Permit pattern variables under disjunctive patterns

Quote of the Day

• "We've so far decided not to decide"

Discussion

Feedback from the C# standardization committee

https://github.com/dotnet/csharpstandard/issues/366

For the first half of today's LDM, we had a guest from the C# standardization committee on to talk about the ongoing process by TC-49 to produce an update to the ECMA C# specification, the latest version of which covers C# 5. In the csharplang repository, we currently have an initial conversion of an internal Microsoft C# specification of C# 3, which was updated to cover some aspects of C# 6. The ECMA team has converted the C# 5 specification to markdown, and is currently working to integrate the changes from our C# 6 spec into that version.

These dual versions of the specification can confuse users. The language reference on docs.microsoft.com comes from the csharplang version of the spec, but the TC-49 version of this specification has had a number of bug fixes and is a better markdown conversion overall. Because of this the csharplang version of the spec gets occasional pull requests to update various things, from English spelling and grammar issues to actual spec bugs, but many times those issues have already been fixed in the TC-49 version of the specification. To address this, we plan to remove the csharplang version of the specification when the last PRs for C# 6 are merged into the csharpstandard repo, which should hopefully be soon.

Additionally, the standardization committee has draft PRs out for most C# 7 features, and is working on C# 8 specifications as well. Currently, when they run into questions they've been emailing a few specific compiler team members, who hopefully can either answer their questions or forward to the right team member. To facilitate better interactions, we've created an internal alias with the compiler team, the language design team, and the TC-49 members currently working on the draft specifications. The specification changes for C# 8 are big, particularly with nullable reference types, and will require close collaboration between these groups to make sure the spec actually reflects the feature that was implemented by the compiler team.

Finally, we did some thinking about how to collaborate moving forward on new language features. We'd like to think about maintaining proposals as branches on the TC-49 specification, to make sure that we are considering the real specification when we think about new language features and ensuring that we can see other proposed changes to the specification as a whole when making new features, as opposed to having to remember what not-yet-specified proposal from a previous language version modified a particular section of the specification while designing a new change to that section.

Permit pattern variables under disjunctive patterns

https://github.com/dotnet/csharplang/issues/4018

We took a first pass over this proposal in the second half of the LDM. At first brush, there are a couple of major points of contention:

1. Should we allow redeclaration, or should we have some form of into pattern that would allow the reuse of an existing variable in a pattern?
2. Is variable declaration across multiple expressions ok, or should it only be permissible within a single pattern?

Point 1 arises from potential confusion around the double declaration: will users find the multiple declarations intuitive, or will they wonder about "which" of the pattern variables future usages refer to? We've also had requests for an into pattern in the past, that would allow a pattern to assign into an existing variable. We're concerned about a generalized version of this pattern because it could have unpredictable effects, particularly when combined with when clauses, but a more specialized version that can only use variables declared in the same pattern could be a usable version of this proposal. We also want to think about how this would interact with any potential pattern matching over types themselves in the future, such as extracting the T from an IEnumerable<T>: if such a thing could be done, it should be doable under an or as well, and we will want to have similar syntax forms for redeclaration as here. We also need consider how an into pattern or other form of assignment syntax would interact if we ever want to permit non-constants to be used as a pattern themselves.

For point 2, we're concerned about the potential large impact throughout the language. This would be very similar to permitting a generalized into pattern, where when clauses can cause otherwise-matching patterns to not be executed and reassign existing variables. Several members of the LDM feel that we should tackle just within a single expression first, and consider multiple expressions at a later time with more examples of the types of code it would enable.

Conclusions

No conclusions today. We want to see the specification PR updated with more motivating samples, including samples from real code, before we make any conclusions on these issues.