C# Language Design Meeting for September 13th, 2021

Agenda

1. Feedback on static abstracts in interfaces

Quote(s) of the Day

• "Computer math never equals real math, it never does"
• "If we add default interface methods to LINQ, we get dim sum."

Discussion

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

Today, we looked at some of the initial feedback we've gotten on both static abstracts in interfaces and generic math from our blog posts and on our design issues. Some of the channels we looked at:

• https://github.com/dotnet/csharplang/issues/4436
• https://github.com/dotnet/designs/pull/205
• https://devblogs.microsoft.com/dotnet/preview-features-in-net-6-generic-math/
• https://www.reddit.com/r/csharp/comments/p20xap/preview_features_in_net_6_generic_math/
• https://www.reddit.com/r/dotnet/comments/p20jlc/preview_features_in_net_6_generic_math/
• https://www.reddit.com/r/programming/comments/p20j22/preview_features_in_net_6_generic_math/
• https://twitter.com/tannergooding/status/1425223277941719040?s=20
• https://twitter.com/dotnet/status/1428127070530514944?s=20

We've also had discussion on our various other platforms not so easily directly linked, such as the C# community discord (https://discord.gg/csharp), email, and other similar informal chats. Overall, we're pleased to see both the number of people looking at the feature, and that their reactions to the feature are overwhelmingly positive. We also received a good deal of concrete feedback we can examine to see what, if anything, we should change or improve about the feature before shipping for real with .NET 7.

Keyword confusion

Some users didn't immediately connect the idea of static and abstract, and suggested that we might want to consider a new keyword specifically for this concept. However, we think this is another case of initial reactions wanting new features to stand out. This is particularly exacerbated because abstract is not used in interfaces today, but is required here. Despite that, we intend to keep the keywords the way we have them: even if we introduced something special for interfaces, we'd want to use static abstract in classes when we support defining such methods there.

Traits/Shapes/Roles

Some of the feedback has been about asking us to go further, into traits/shapes/roles/type expansion du jour. This is only natural: static abstracts represents a major new expressive ability in C#, and these types of expansions are the logical next step. While the feature we're currently working is not going to address those requests, we by no means are done in this space, and will continue to explore more enhancements we can make in this space.

Missing types

We didn't get to implementing the generic math interfaces on all types that would benefit from them in .NET 6, such as BigInteger or Vector2/3/4. We plan to expand our implementations on these interfaces with .NET 7 to cover more types.

Direct parsing support in INumber

Some users have expressed a sentiment that proper mathematical numbers don't necessarily have serialization/deserialization as a concept, and thus asked for INumber to not include those concepts in the extended interface set. This will be a question for the runtime API reviewers to think on.

Self types

Of the biggest pieces of feedback we've gotten is around confusing on type constraints. In particular, users expect calls like IParsable<double>.Parse("123", null) to work, but because of the way we've implemented the type constraints currently, the language cannot understand that double is the type that Parse needs to be constrained to. We can solve issues like this by implementing a self type, which will also just be a generally-useful feature for the language. We're positive about the feature, but it is going to need a decent amount of design work. In particular, there are interfaces such as IEquatable<T> that have been in C# since C# 2.0, and we need to think about if we want to be able to apply such a constraint to those interfaces, how that would work, and what level of breaking change it would be. There is also syntax to be worked out, which makes for everyone's favorite LDMs.

DIMs for static abstracts

We consider the ability to have a DIM for static virtual members a must-have for v1, as we'll need it for versioning, and potentially some of the initial implementation will want to be a DIM instead of being required to be implemented by users.

static abstracts in classes

The ability to declare static abstract members in classes will almost certainly be in the runtime for .NET 7. However, we don't consider it as important of a ship-blocker as the DIM feature, so it might have less priority than other C# 11 features.

Checked operators

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

We think this operator is likely important for semantic correctness in generic math. It's a niche case, and we may want to use the afformentioned DIMs to forward the checked implementation to unchecked, but that will be a decision for the runtime API design team.

Relaxing shift operator requirements.

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

Our thoughts on this proposal have not changed since the last time we looked at it.