rbwhitaker
commented
1 year ago The barebones concept of static members in an interface is straightforward but not very helpful. You can add them with a static abstract on the member (the abstract is mandatory, unlike normal members where it is implied) but then there's not a good way to use them. To access a static member, you typically access it through the class name. So you can't access these static members through the interface name. That path is a non-starter.
Besides, interfaces are about defining the boundary of objects (or parts of the object boundary) so that you can easily swap one object for another. Static members are not about the boundaries of objects at all. So they're not a great fit.
However, they do make more sense with generics, where the type is swappable, and with operators, where the definition is done statically, but where you're working with instances of the type.
At any rate, I've added a minimal amount of information to the book about static interface members, but mostly, I call out a set of blog posts that cover generic math (and operators and generic math algorithms, etc.) in depth there, since it isn't something that most people will do much with in the months after reading the book.
You can add
static abstractmembers to an interface now. This allows you to demand that a type implements some specific operator or conversion, and it also allows you to define a factory method.