# C# Language Design Meeting for Feb 24th, 2021

## Agenda

1. [Static abstract members in interfaces](#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:

```cs
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.