- "I'm not using the monoid word, I'm trying to make it relatable"
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.
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().
We don't have any strong feelings on allowing sealed on non-virtual static interface members. It's fine to include in the proposal.
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.