Почему этот сценарий дженериков вызывает исключение TypeLoadException?

Это ошибка — см. Реализация универсального метода из универсального интерфейса вызывает исключение TypeLoadException и method-with-type-parameter-constraint" rel="nofollow">Непроверяемый код с универсальным интерфейсом и универсальным методом с ограничением параметра типа. Однако мне не ясно, является ли это ошибкой С# или ошибкой CLR.

[Добавлено ОП:]

Вот что говорит Microsoft во второй ветке, на которую вы ссылаетесь (выделено мной):

Существует несоответствие между алгоритмами, используемыми средой выполнения и компилятором C# для определения того, является ли один набор ограничений таким же сильным, как другой набор. Это несоответствие приводит к тому, что компилятор C# принимает некоторые конструкции, которые среда выполнения отклоняет, и в результате вы видите исключение TypeLoadException. Мы проводим расследование, чтобы определить, является ли этот код проявлением этой проблемы. Тем не менее, компилятор, безусловно, не принимает такой код, что приводит к исключению во время выполнения.

С уважением,

Эд Маурер Ведущий специалист по разработке компилятора C#

Из части, которую я выделил жирным шрифтом, я думаю, что он говорит, что это ошибка компилятора. Это было еще в 2007 году. Я думаю, это не настолько серьезно, чтобы это было приоритетом для их исправления.

Единственное объяснение состоит в том, что ограничение считается частью объявления метода. Поэтому в первом случае это ошибка компилятора.

Компилятор не получает ошибку при использовании object... ну, это ошибка компилятора.

Другие «ограничения» имеют те же свойства, что и общее ограничение:

interface I
{
    object M();
}

class C
{
    public some_type M() { return null; }
}

class D : C, I
{
}

Я мог бы спросить: почему это не работает?

Понимаете? Это точно такой же вопрос, как и ваш. Вполне допустимо реализовать object с some_type, но ни среда выполнения, ни компилятор этого не примут.

Если вы попытаетесь сгенерировать код MSIL и принудительно реализовать мой пример, среда выполнения будет жаловаться.

Неявная реализация интерфейса требует, чтобы универсальные ограничения для объявлений методов были эквивалентны, но не обязательно точно такими же в коде. Кроме того, параметры универсального типа имеют неявное ограничение «where T : object». Вот почему указание компиляции C<Object> приводит к тому, что ограничение становится эквивалентным неявному ограничению в интерфейсе. (Раздел 13.4.3 документа Спецификация языка C#).

Вы также правы в том, что использование явной реализации интерфейса, которая вызывает ваш ограниченный метод, будет работать. Он обеспечивает очень четкое сопоставление метода интерфейса с вашей реализацией в классе, где ограничения не могут различаться, а затем переходит к вызову универсального метода с таким же именем (тот, который теперь не имеет ничего общего с интерфейс). В этот момент ограничения для вторичного метода могут быть разрешены так же, как и вызов любого универсального метода без каких-либо проблем с разрешением интерфейса.

Перемещение ограничений из класса в интерфейс во втором примере лучше, потому что класс по умолчанию будет брать свои ограничения из интерфейса. Это также означает, что вы должны указать ограничения в реализации вашего класса, если они применимы (а в случае Object это неприменимо). Передача I<string> означает, что вы не можете напрямую указать это ограничение в коде (поскольку строка запечатана), поэтому оно должно быть либо частью явной реализации интерфейса, либо универсальным типом, который будет равен ограничениям в обоих местах.

Насколько мне известно, среда выполнения и компилятор используют разные системы проверки ограничений. Компилятор допускает этот случай, но верификатору времени выполнения он не нравится. Я хочу подчеркнуть, что я точно не знаю, почему у него проблемы с этим, но я предполагаю, что ему не нравится потенциал в этом определении класса, чтобы не выполнять ограничения интерфейса в зависимости на что в конечном итоге устанавливается T. Если у кого-то еще есть окончательный ответ на этот вопрос, это было бы здорово.

В ответ на ваш фрагмент интерфейса:

interface I<T1>
{
    void Foo<T2>() where T2 : T1;
}

class C : I<string> // compiler error CS0425
{
    public void Foo<T>() { }
}

Я считаю, что проблема в том, что компилятор распознает, что:

1. вы не объявили необходимые ограничения типа для C.Foo().
2. если вы выберете строку в качестве своего типа, в C.Foo() не будет допустимого T, поскольку тип не может наследоваться от строки.

Чтобы увидеть эту работу на практике, укажите фактический класс, который может быть унаследован как T1.

interface I<T1>
{
    void Foo<T2>() where T2 : T1;
}

class C : I<MyClass>
{
    public void Foo<T>() where T : MyClass { }
}

public class MyClass
{
}

Чтобы показать, что тип string никоим образом не обрабатывается особым образом, просто добавьте ключевое слово sealed в объявление MyClass выше, чтобы увидеть, что он потерпит неудачу точно так же, как если бы вы укажите T1 как строку вместе со строкой в ​​качестве ограничения типа для C.Foo().

public sealed class MyClass
{
}

Это связано с тем, что строка запечатана и не может служить основой для ограничения.