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

## Agenda

1. [Feedback on static abstracts in interfaces](#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 abstract`s 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](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-19.md#relaxing-shift-operator-requirements)
we looked at it.
