Do we *want* to allow non-virtual declarations in interfaces? In practice you probably at least want private methods. But it's likely you'll want internal, and maybe public. What's the syntactic distinction from normal "virtual/abstract" interface members?:
Should an interface be required to put `abstract` in order to allow derived interfaces to override them? No. So it probably also shouldn't require `virtual`. So it's the "virtualness" that's implicit, not specifically the "abstractness".
The core motivating scenario is default-ness of implementations. So that is the thing we should design around. Is the copy-paste scenario between interfaces and classes important? It already is very far from possible. For instance, property declarations in interfaces today are syntactically identical to auto-properties in classes today!
Requiring a modifier (e.g. `virtual`) on a virtual interface member with a default member, as in `I1` and `I3` above, causes an inconsistency between interface members with and without default implementations.
Also, taking unmodified members with bodies to be non-virtual, as in `I1` above, is a bit dangerous: adding a body changes the member from virtual to non-virtual. While an implementing class may still think it is implicitly implementing the member, it is in fact just declaring an unrelated member:
- Non-virtualness should be explicitly expressed through `sealed`
- We want to allow all modifiers in interfaces, in analogy with classes, but with different defaults
- Default accessibility for interface members is public, including for nested types
-`private` function members in interfaces are implicitly `sealed`, and `sealed` is not permitted on them. `private` nested *classes* can be `sealed`, and that means `sealed` in the class sense.
Just as with anonymous types we pick up names from expressions that are simple names (`x`), dotted names (`e.x`) and `?.`'ed names (`e?.x`).
This is technically a breaking change from C# 7.0, but it is quite esoteric. It is hard to construct an example where you depend on a tuple element *not* having a particular name, but here's one:
There are some gnarly issues questions around tuple element names in generic constraints. In general we try to avoid use of different tuple element names across related declarations, but with constraints it is hard.
We think you could never declare a class (in C#) that satisfies the constraints (in C#) in these examples. You could construct things in IL to circumvent, but it's ok for us not to deal with that. So it's probably ok for C# not emit an error here.