# C# Language Design Meeting for September 15th, 2021

## Agenda

* [Feedback from the C# standardization committee](#feedback-from-the-c-standardization-committee)
* [Permit pattern variables under disjunctive patterns](#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.

