为什么 C# 泛型不能像在 C++ 模板中那样从泛型类型参数之一派生? [英] Why cannot C# generics derive from one of the generic type parameters like they can in C++ templates?
问题描述
为什么 C# 泛型不能像在 C++ 模板中那样从泛型类型参数之一派生?我的意思是我知道这是不可能的，因为 CLR 不支持这个，但为什么呢?
Why cannot C# generics derive from one of the generic type parameters like they can in C++ templates? I mean I know it impossible because CLR does not support this, but why?
我知道 C++ 模板和 C# 泛型之间的深刻区别 - 前者是编译时实体，必须在编译期间解析，而后者是第一类运行时实体.
I am aware of the profound differences between C++ templates and C# generics - the former are compile time entities and must be resolved during the compilation, while the latter are first class run-time entities.
仍然，我没有看到原因为什么 CLR 设计者没有想出一种方案来最终使 CLR 泛型类型能够从其泛型类型参数中的一个派生.毕竟，这将是非常有用的功能，我个人非常想念它.
Still, I am failing to see the reason why CLR designers did not come up with a scheme which would ultimately enable a CLR generic type to derive from one of its generic type parameters. After all, this would be tremendously useful feature, I personally miss it greatly.
我想知道一个核心问题，解决这个问题会导致实施此功能的成本如此之高，这证明它尚未实施是合理的.例如，检查这个虚构的声明:
I would like to know of a hard-core issue, fixing which yields such a high price on implementing this feature that justifies it not being implemented yet. For instance, examine this fictional declaration:
class C<T> : T
{
}
正如 Eric Lippert 已经注意到如果如果 T 是一个结构会怎样?如果 T 是密封类类型会怎样?如果 T 是一个接口类型会怎样?如果 T 是 C 会怎样?！如果 T 是一个会怎样?从 C 派生的类?如果 T 是具有抽象方法的抽象类型怎么办?如果 T 的可访问性比 C 少怎么办?如果 T 是 System.ValueType 怎么办?(你能有一个继承自 System.ValueType 的非结构体吗?)System.Delegate、System.Enum 等呢?"
As Eric Lippert has noticed what if "What if T is a struct? What if T is a sealed class type? What if T is an interface type? What if T is C?! What if T is a class dervied from C? What if T is an abstract type with an abstract method? What if T has less accessibility than C ? What if T is System.ValueType? (Can you have a non-struct which inherits from System.ValueType?) What about System.Delegate, System.Enum, and so on?"
Eric 继续说道，那些是简单、明显的".的确，他是对的.我对一些既不简单也不明显的问题的具体例子感兴趣，这个问题很难解决.
As Eric continues, "Those are the easy, obvious ones". Indeed, he is right. I am interested in a concrete example of some neither easy nor obvious issue, which is hard to resolve.
推荐答案
好吧，首先问问自己 class C.大量的事情立即浮现在脑海中:
Well, start by asking yourself what could possibly go wrong with class C<T> : T { }. A huge number of things come immediately to mind:
如果 T 是一个结构体呢?如果 T 是密封类类型怎么办?如果 T 是接口类型怎么办?如果 T 是 C 怎么办?！如果 T 是从 C 派生的类怎么办?如果 T 是具有抽象方法的抽象类型怎么办?如果 T 的可访问性比 C 低怎么办?如果 T 是 System.ValueType 呢?(你能有一个继承自 System.ValueType 的非结构体吗?)System.Delegate、System.Enum 等等呢?
What if T is a struct? What if T is a sealed class type? What if T is an interface type? What if T is C<T>?! What if T is a class derived from C<T>? What if T is an abstract type with an abstract method? What if T has less accessibility than C ? What if T is System.ValueType? (Can you have a non-struct which inherits from System.ValueType?) What about System.Delegate, System.Enum, and so on?
那些是简单明了的.提议的特性会引发数百个甚至数千个关于类型与其基本类型之间交互的微妙问题，所有这些问题都必须仔细指定、实现和测试.毫无疑问，我们会错过一些，从而导致未来发生重大变化，或者使运行时具有实现定义的行为.
Those are the easy, obvious ones. The proposed feature opens up literally hundreds, if not thousands of more subtle questions about the interaction between the type and its base type, all of which would have to be carefully specified, implemented and tested. We'd undoubtedly miss some, and thereby cause breaking changes in the future, or saddle the runtime with implementation-defined behaviour.
成本是巨大的，所以收益最好是巨大的.我在这里没有看到巨大的好处.
The costs would be enormous, so the benefit had better be enormous. I'm not seeing an enormous benefit here.
这篇关于为什么 C# 泛型不能像在 C++ 模板中那样从泛型类型参数之一派生?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
