C# Language Design Meeting for May 19th, 2021

Agenda

Triage
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.