5.4 KiB
C# Language Design Meeting for May 19th, 2021
Agenda
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.