为什么不输入方法签名的制约一部分？ [英] Why aren't type constraints part of the method signature?
问题描述
所以我读<一个href=\"http://blogs.msdn.com/b/ericlippert/archive/2009/12/10/constraints-are-not-part-of-the-signature.aspx\"相对=nofollow>埃里克利珀的约束不是签名的组成部分，现在我明白了规范指定重载决议之后检查该类型的限制，但我仍然不为什么这必须清除是这种情况。下面是Eric的例子：
So I read Eric Lippert's 'Constraints are not part of the signature', and now I understand that the spec specifies that type constraints are checked AFTER overload resolution, but I'm still not clear on why this MUST be the case. Below is Eric's example:
static void Foo<T>(T t) where T : Reptile { }
static void Foo(Animal animal) { }
static void Main()
{
Foo(new Giraffe());
}
这不会编译，因为重载解析为：美孚（新长颈鹿（））推断美孚＆LT;长颈鹿＆GT; 是最好的超负荷比赛，但随后的类型约束失败，编译时引发错误。在埃里克的话：
This doesn't compile because overload resolution for: Foo(new Giraffe()) infers that Foo<Giraffe> is the best overload match but then the type constraints fail and a compile-time error is thrown. In Eric's words:
这里的原则是重载解析（和方法类型推断）发现的参数列表，每个候选方法的形参列表之间的最佳匹配。也就是说，他们在看候选方法的签名。
The principle here is overload resolution (and method type inference) find the best possible match between a list of arguments and each candidate method’s list of formal parameters. That is, they look at the signature of the candidate method.
类型约束不是签名的组成部分，但他们为什么不能呢？什么是一些场景中它是一个坏主意，考虑签名的类型约束一部分？难道仅仅是很难或不可能实现？我不主张，如果选择最好的超负荷无论出于何种原因无法调用，然后默默退到第二个最好的;我讨厌这样。我只是想了解为什么类型约束不能被用来影响的最佳超载的选择。
Type constraints are NOT part of the signature, but why can't they be? What are some scenarios where it is a bad idea to consider type constraints part of the signature? Is it just difficult or impossible to implement? I'm not advocating that if the best chosen overload is for whatever reason impossible to call then silently fallback to the second best; I would hate that. I'm just trying to understand why type constraints can't be used to influence the choosing of the best overload.
我想象中的内部C＃编译器，的只重载目的（它不会永久改写法）的，如下：
I'm imagining that internally in the C# compiler, for overload resolution purposes only (it doesn't permanently rewrite the method), the following:
static void Foo<T>(T t) where T : Reptile { }
被转化为：
static void Foo(Reptile t) { }
你为什么不能排序的拉式限制进入正式的参数列表？这是如何更改签名的任何坏的方式？我觉得这只会强化签名。然后美孚＆LT;爬行方式＆gt; 将永远不会被视为超载候选人
Why can't you sort of "pull in" the type constraints into the formal parameter list? How does this change the signature in any bad way? I feel like it only strengthens the signature. Then Foo<Reptile> will never be considered as an overload candidate.
编辑2：难怪我的问题是如此混乱。我没有正确读取埃里克的博客，我引用了错误的榜样。我在我认为比较合适的例子编辑。我也改变了标题更具体。这个问题似乎并不那么简单，我首先想到，也许我错过了一些重要的概念。我不太确定这是计算器的材料，它可能是最适合这个问题/讨论被移到别处。
Edit 2: No wonder my question was so confusing. I didn't properly read Eric's blog and I quoted the wrong example. I've edited in the example I think more appropriate. I've also changed the title to be more specific. This question doesn't seem as simple as I first imagined, perhaps I'm missing some important concept. I'm less sure that this is stackoverflow material, it may be best for this question/discussion to be moved elsewhere.
推荐答案
C＃编译器有没有考虑类型约束的一部分，该方法的签名，因为他们不是为CLR方法签名的一部分。如果过载分辨率为不同语言（主要是动态绑定由于可以在运行时发生的，不应该是从一种语言互不相同，否则所有的地狱将挣脱）。
The C# compiler has to not consider type constraints as part as the method signature because they are not part of the method signature for the CLR. It would be disastrous if the overload resolution worked differently for different languages (mainly due to the dynamic binding that may happen at runtime and should not be different from one language to another, or else all hells would break loose).
为什么会决定，这些限制不会为CLR方法签名的一部分，是另一个问题产品总数，而我只能作出有关不了解情况的推测。我会让在知道人回答这个问题。
Why was it decided that these constraints would not be part of the method signature for the CLR is another question alltogether, and I could only make ill informed suppositions about that. I'll let the people in the know answer that.
这篇关于为什么不输入方法签名的制约一部分？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
