# C# Language Design Meeting for May 19th, 2021

## Agenda

1. [Triage](#triage)
    1. [Checked operators](#checked-operators)
    2. [Relaxing shift operator requirements](#relaxing-shift-operator-requirements)
    3. [Unsigned right shift operator](#unsigned-right-shift-operator)
    4. [Opaque parameters](#opaque-parameters)
    5. [Column mapping directive](#column-mapping-directive)
    6. [Only allow lexical keywords](#only-allow-lexical-keywords)
    7. [Allow nullable types in declaration patterns](#allow-nullable-types-in-declaration-patterns)
2. [Protected interface methods](#protected-interface-methods)

## Quote of the Day

- "I feel like I've known this before and then I packed it away in some chamber of horrors in my brain"

## Discussion

### Triage

#### Checked operators

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

There are some complexities to this proposal (such as betterness rules between checked and unchecked operators), how it will affect VB, and some
potential clunkiness in the interface definitions (`int` shift doesn't overflow today even in checked contexts, but would need to expose both?),
but we think that this is pretty essential to a well-formed generic math interface structure.

##### Conclusion

Triaged into the working set.

#### Relaxing shift operator requirements

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

We have some immediate visceral reactions to this, but it's been 21+ years of BCL and other library design and we don't see huge abuse of other
operators. It might be time to lift the restriction here.

##### Conclusion

Triaged into the working set.

#### Unsigned right shift operator

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

This is an odd missing operator in general, and a hole in our design for generic math that similar libraries in other languages have filled.

##### Conclusion

Triaged into the working set.

#### Opaque parameters

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

We're not a huge fan of how this silently munges with the method signature, and the number of cliffs there are: what happens when a user wants
2 of these parameters with the same type, or wants to add multiple constraints to a type parameter?

##### Conclusion

Rejected. It's possible we could revisit flavors of this with associated types at a later point, but as is this is rejected.

#### Column mapping directive

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

We have a few open questions, such as whether we need an end offset as well. However, overall this looks good. These directives are basically
never human-written or read, and it helps solve problems for partner teams using C# as a DSL.

##### Conclusion

Triaged into the working set.

#### Only allow lexical keywords

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

This is a discussion that has been building in the LDM for years, particularly around older contextual keywords such as `var` and `dynamic`
used in a type position. We think there are two broad categories of contextual keywords here: keywords that we think are "safe" to reserve,
such as the aforementioned `var`, that are used in positions where standard C# conventions wouldn't allow things to be named in a conflicting
manner: types, for example, are PascalCase by convention in C#, and `var` starts with a lowercase character. Making a break here helps _both_
the compiler team and the average language user, as it simplifies the language and isn't likely to break code that isn't intentionally trying
to avoid the feature. There are other keywords though, such as `yield`, that we think are good to keep as contextual keywords. It makes the
compiler team's life more difficult, but it helps users, and we don't want to make changes here just to make the compiler's job a bit easier.
We think there's opportunity to do work here in the first set, particularly if we take a phased approach where we warn about a keyword in C#
X and then totally deprecate in Y.

##### Conclusion

Triaged into the working set. We'll revisit soon to think about the phased strategy and see what we want to do for C# 10.

#### Allow nullable types in declaration patterns

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

There are some really gnarly parsing ambiguities here, but even if we could solve the compiler parsing problem, the human parsing problem will
remain. We don't think those problems are really solveable, and that the gain isn't worth the complexity.

##### Conclusion

Rejected.

### Protected interface methods

https://github.com/dotnet/csharplang/discussions/4718

When DIMs were initially implemented, we were concerned about a `public` member in a type named the same as a `protected` member in an interface
that type is implementing being confused for an implicit implementation of that `protected` member. However, this ends up somewhat hindering the
goal of DIMs in the first place, which was making adding new methods to an interface not be a breaking change. Given this, and given that the
future option for _having_ implicit `protected` interface member implementation was already removed in V1 of DIMs, we'd like to remove this
restriction. We don't think we can treat this as a bugfix, despite the low impact nature, as it was intentional and C# 8 has been out for a year
and a half now. The hardest part will be coming up with a name for the compiler error message: perhaps "Relaxed DIM requirements for non-public
members".

#### Conclusion

We'll relax this restriction as a new language feature.
