csharplang/meetings/2021/LDM-2021-02-24.md

C# Language Design Meeting for Feb 24th, 2021

Agenda

1. Static abstract members in interfaces

Quote of the Day

• "I'm not using the monoid word, I'm trying to make it relatable"

Discussion

Static abstract members in interfaces

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

Today we went over the proposed specification for static abstract members. In order to scope the initial implementation, this proposal intentionally limits such members to only abstract members, not virtual members. This is due to complexity in passing along the "instance" that the static is operating on. Consider this example:

interface I
{
    virtual static void I1() { I2(); }
    abstract static I2();
}

class C : I
{
    public static void I2() {}
}

C.I1();
// How does the runtime pass along the information that the type here is C,
// and I.M1() should invoke C.I2()?

Given the complexity of implementation of this scenario and the lack of current motivating examples, we will push this out for a later version unless our investigations of representing generic math end up needing it.

== and != operators

These are restricted in interfaces today because interface types cannot implement object.Equals(object other) and object.GetHashcode(), which are integral to implementing the operators correctly. We can lift that restriction for abstract static members, as the implementing concrete type will then be required to provide implementations of Equals(object other) and GetHashcode().

sealed on non-abstract members

We don't have any strong feelings on allowing sealed on non-virtual static interface members. It's fine to include in the proposal.

Conversion restrictions

As we implement a set of math interfaces, we'll come across parts of the current restrictions that make it impossible. We should be cautious here and only lift restrictions as much as is necessary to implement the target scenarios. We can review the rules in depth when they have been proven out by final usage.