19

这有点冗长，所以这里是快速版本：

为什么这会导致运行时 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' 试图隐式实现具有较弱类型参数约束的接口方法。”

但是这个错误在技术上不是错误的吗？不使用ObjectforC<T1>否定对 的约束C.Foo()，从而使其等效于 - NOT 强于 - 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 以外的任何其他内容，这将无法编译。我觉得这样做有点脏，因为我不确定它是否故意这样工作。

4

4 回答 4

4

这是一个错误 - 请参阅从通用接口实现通用方法导致 TypeLoadException和Unverifiable Code with Generic Interface 和 Generic Method with Type Parameter Constraint。不过，我不清楚这是 C# 错误还是 CLR 错误。

[由OP添加：]

这是微软在您链接到的第二个线程中所说的（我的重点）：

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

问候，

Ed Maurer C# 编译器开发主管

从我加粗的部分来看，我认为他说这是一个编译器错误。那是在 2007 年。我想这还不够严重，不足以成为他们修复它的优先事项。

于 2011-05-20T20:34:17.397 回答
3

隐式接口实现要求方法声明上的通用约束是等价的，但在代码中不一定完全相同。此外，泛型类型参数具有“where T : object”的隐式约束。这就是为什么指定C<Object>编译，它会导致约束变得等同于接口中的隐式约束。（C# 语言规范第 13.4.3 节）。

您也正确的是，使用调用受约束方法的显式接口实现将起作用。它提供了从接口方法到约束不能不同的类中的实现的非常清晰的映射，然后继续调用类似名称的泛型方法（现在与接口无关的方法）。此时，可以像任何通用方法调用一样解决辅助方法的约束，而不会出现任何接口解析问题。

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

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

于 2011-05-18T20:42:01.993 回答
3

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

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

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

interface I
{
    object M();
}

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

class D : C, I
{
}

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

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

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

于 2011-05-16T02:28:27.960 回答
0

响应您基于界面的代码段：

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
{
}

为了表明字符串类型没有以任何方式被特殊对待，只需将密封关键字添加到上面的 MyClass 声明中，如果您将 T1 指定为字符串以及将字符串指定为 C 上的类型约束，则它会以相同的方式失败。富（）。

public sealed class MyClass
{
}

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

于 2011-05-19T03:04:05.970 回答