Здравствуйте, Sinclair, Вы писали:

S>А запрет на виртуальные методы в данном контексте плавно превращается в запрет реализовывать интерфейсы, чтобы избежать странных эффектов.
S>Ну, либо правила определения того, что можно, а что нельзя, становятся чрезмерно сложными.

У value-типов исключили VMT, отсюда остальные правила выводятся автоматически, даже в случае разрешения наследования структур.
Например, по ссылке на value-тип волей-неволей придётся считать, что это точный тип.

Соотв., реализация интерфейсов должна быть в этом типе, потому что интерфейсные методы будут вызываться непосредственно.

Во время боксирования в куче тоже создаётся объект с типом ссылки и копируется тело известной структуры, а не неизвестного наследника.

Насчёт разруливания интерфейсов в боксированных значениях — там пока мест не видно никаких сложностей, можно брать готовый механизм из классов (а другого и не будет для боксированных значений).

Брать надо тот механизм где метод, реализующий интерфейс, не объявлен виртуальным (как оно происходит в случае структур).
Тогда одноимённый метод в классе-наследнике рассматривается уже как new, т.е. не переопределяет интерфейсный метод базового класса.

Чтобы в наследнике переопределить нужный метод интерфейса, надо наследнику опять указать в списке баз интерфейс и тогда уже переопределить интерфейсный метод одним из доступных способов:

interface I {
    void Foo();
    void Bar();
}

class Base : I {
    public void Foo() {}
    public void Bar() { }
}

class Derived : Base, I {
    void I.Foo() {}
}

Если бы существовало наследование структур, то здесь достаточно было бы заменить class на struct, т.е. имеющиеся реализованные правила мэппинга методов интерфейсов на методы классов и так обеспечивают требуемую семантику.

Здравствуйте, Sinclair, Вы писали:

S>А запрет на виртуальные методы в данном контексте плавно превращается в запрет реализовывать интерфейсы, чтобы избежать странных эффектов.
S>Ну, либо правила определения того, что можно, а что нельзя, становятся чрезмерно сложными.

У value-типов исключили VMT, отсюда остальные правила выводятся автоматически, даже в случае разрешения наследования структур.
Например, по ссылке на value-тип волей-неволей придётся считать, что это точный тип.

Соотв., реализация интерфейсов должна быть в этом типе, потому что интерфейсные методы в генериках будут вызываться непосредственно.

Во время боксирования в куче тоже создаётся объект с типом ссылки и копируется тело известной структуры, а не неизвестного наследника.

Насчёт разруливания интерфейсов в боксированных значениях — там пока мест не видно никаких сложностей, можно брать готовый механизм из классов (а другого и не будет для боксированных значений).

Брать надо тот механизм где метод, реализующий интерфейс, не объявлен виртуальным (как оно происходит в случае структур).
Тогда одноимённый метод в классе-наследнике рассматривается уже как new, т.е. не переопределяет интерфейсный метод базового класса.

Чтобы в наследнике переопределить нужный метод интерфейса, надо наследнику опять указать в списке баз интерфейс и тогда уже переопределить интерфейсный метод одним из доступных способов:

interface I {
    void Foo();
    void Bar();
}

class Base : I {
    public void Foo() {}
    public void Bar() { }
}

class Derived : Base, I {
    void I.Foo() {}
}

Если бы существовало наследование структур, то здесь достаточно было бы заменить class на struct, т.е. имеющиеся реализованные правила мэппинга методов интерфейсов на методы классов и так обеспечивают требуемую семантику.