Question

这有点啰嗦，所以这是快速版本：

为什么会导致运行时出现TypeLoadException？（编译器是否会阻止我这样做？）

interface I
{
    void Foo<T>();
}

class C<T1>
{
    public void Foo<T2>() where T2 : T1 { }
}

class D : C<System.Object>, I { }

如果您尝试实例化D，则会发生异常。

更长，更具探索性的版本：

考虑：

interface I
{
    void Foo<T>();
}

class C<T1>
{
    public void Foo<T2>() where T2 : T1 { }
}

class some_other_class { }

class D : C<some_other_class>, I { } // compiler error CS0425

这是非法的，因为C.Foo()上的类型限制与I.Foo()上的类型限制不匹配。它会生成编译器错误CS0425。

但我认为我可以打破这个规则：

class D : C<System.Object>, I { } // yep, it compiles

通过使用Object作为T2的约束，我否定该约束。我可以安全地将任何类型传递给D.Foo<T>()，因为所有类型都来自Object。

即便如此，我仍然期望得到编译器错误。在C＃语言意义上，它违反了“C.Foo（）上的约束必须与I.Foo（）上的约束相匹配的规则”，我认为编译器会成为规则。但它确实编译。似乎编译器看到了我正在做的事情，理解它是安全的，并且视而不见。

我以为我已经离开了它，但运行时说没那么快。如果我尝试创建D的实例，我会得到一个TypeLoadException：“类型'D'上的方法'C`1.Foo'试图隐式地实现具有较弱类型参数约束的接口方法。”

但这不是技术错误吗？不使用Object C<T1>否定C.Foo()上的约束，从而使其等于 - 不强于 - I.Foo()？编译器似乎同意，但运行时没有。

为了证明我的观点，我将D排除在等式之外进行了简化：

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

class some_other_class { }

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

可是：

class C : I<Object> // compiles
{
    public void Foo<T>() { }
}

这适用于传递给Foo<T>()的任何类型的编译和运行。

为什么呢？运行时是否存在错误，或者（更有可能）是否存在我未看到此异常的原因 - 在哪种情况下编译器不应该阻止我？

有趣的是，如果通过将约束从类移动到接口来反转方案......

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

class C
{
    public void Foo<T>() { }
}

class some_other_class { }

class D : C, I<some_other_class> { } // compiler error CS0425, as expected

我再次否定了这个限制：

class D : C, I<System.Object> { } // compiles

这次它运行正常！

D d := new D();
d.Foo<Int32>();
d.Foo<String>();
d.Foo<Enum>();
d.Foo<IAppDomainSetup>();
d.Foo<InvalidCastException>();

一切顺利，这对我来说非常有意义。（与等式中的D相同）

那么为什么第一种方式会破裂？

附录：

我忘了补充说TypeLoadException有一个简单的解决方法：

interface I
{
    void Foo<T>();
}

class C<T1>
{
    public void Foo<T2>() where T2 : T1 { }
}

class D : C<Object>, I 
{
    void I.Foo<T>() 
    {
        Foo<T>();
    }
}

明确实施I.Foo()很好。只有隐式实现会导致TypeLoadException。现在我可以这样做：

        I d = new D();
        d.Foo<any_type_i_like>();

但它仍然是一个特例。尝试使用除System.Object之外的任何其他内容，这将无法编译。我觉得这样做有点脏，因为我不确定它是否故意以这种方式运作。

Answer 1

这是一个错误 - 请参阅Implementing Generic Method From Generic Interface Causes TypeLoadException和Unverifiable Code with Generic Interface and Generic Method with Type Parameter Constraint。但是，我不清楚它是C＃bug还是CLR bug。

[由OP添加]

以下是微软在您链接的第二个帖子中所说的内容（我的重点）：

之间存在不匹配   运行时使用的算法和   C＃编译器确定是否有一组   约束与另一个一样强烈   组。这种不匹配导致C＃   编译器接受一些结构   运行时拒绝和   结果是TypeLoadException你   看到。我们正在调查以确定   如果这个代码是一个表现形式   那个问题。无论如何，确实如此   肯定不是“按设计”那个   编译器接受像这样的代码   导致运行时异常。

此致
      Ed Maurer C＃编译器开发   铅

从我加粗的部分，我认为他说这是一个编译器错误。那是在2007年。我想这并不足以成为他们解决问题的优先事项。

Answer 2

唯一的解释是约束被视为方法声明的一部分。这就是为什么在第一种情况下它是编译器错误。

编译器在使用object时没有收到错误......好吧，这是编译器的错误。

其他“约束”具有与通用约束相同的属性：

interface I
{
    object M();
}

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

class D : C, I
{
}

我可以问：为什么这不起作用？

你知道吗？这和你的问题完全一样。使用object实现some_type是完全有效的，但运行时和编译器都不会接受它。

如果您尝试生成MSIL代码并强制执行我的示例，则运行时会抱怨。

Answer 3

隐式接口实现要求方法声明的泛型约束是等效的，但在代码中不一定完全相同。另外，泛型类型参数具有“where T：object”的隐式约束。这就是为什么指定C<Object>编译，它会使约束变得等同于接口中的隐式约束。（C# Language Spec的第13.4.3节）。

使用显式接口实现来调用约束方法也是有效的。它提供了从接口方法到约束不能不同的类中的实现的非常清晰的映射，然后继续调用类似命名的泛型方法（现在与方法无关）接口）。此时，可以使用与任何通用方法调用相同的方式解决对辅助方法的约束，而不会出现任何接口解析问题。

在第二个示例中，将约束从类移动到接口更好，因为默认情况下，类将从接口中获取约束。这也意味着您必须在类实现中指定约束（如果适用）（对于Object，它不适用）。传递I<string>意味着您不能在代码中直接指定该约束（因为字符串是密封的），因此它必须是显式接口实现的一部分或者是两个地方的约束等于它的泛型类型

据我所知，运行时和编译器对约束使用单独的验证系统。编译器允许这种情况，但运行时验证程序不喜欢它。我想强调一点，我不知道为什么它有这个问题，但我猜它不喜欢该类定义的潜力不满足接口约束什么T最终被设置为。如果其他人对此有明确的答案，那就太棒了。

Answer 4

响应基于界面的代码段：

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

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

我认为问题在于编译器正在认识到：

您尚未在C.Foo（）上声明必要的类型约束。
如果选择字符串作为类型，则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
{
}

要显示字符串类型没有被处理为特殊，只需将密封关键字添加到上面的MyClass声明中，看它是否以相同的方式失败，如果你要将T1和string一起指定为字符串作为C.Foo（）的类型约束。

public sealed class MyClass
{
}

这是因为字符串是密封的，不能构成约束的基础。

为什么这个泛型场景会导致TypeLoadException？

4 个答案: