56 строки
2.0 KiB
Markdown
56 строки
2.0 KiB
Markdown
|
# 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.
|