没有特别的原因选择了这个订单。所选择的顺序从更一般到更具体，我认为是一个相当不错的属性。

There's no particular reason why that order was chosen. The chosen order goes from more general to more specific, which I suppose is a reasonably nice property.

至于问题为什么要求一个订单？更容易的实施和测试团队要有一个清晰，明确的语言强加的顺序。我们可以允许约束以任何顺序出现，但是我们买什么呢？

As for the question "why require an order at all?", it's simply easier on the implementation and testing teams to have a clear, unambiguous order imposed by the language. We could allow the constraints to come in any order, but what does that buy us?

我在语言工作的时间越长，我就越认为每次你给用户一个选择，你给他们一个机会做一个坏的选择。 C＃的一个基本设计原则是，当事情出错时，我们告诉你，并强迫你使它们正确 - 这不是JavaScript的基本设计原则。它的基本设计原则是浑然天成，试图做用户的意思。通过对C＃中的正确语法添加更多限制，我们可以更好地确保在程序中表达所期望的语义。

The longer I work on languages the more I'm of the opinion that every time you give the user a choice, you give them an opportunity to make a bad choice. A basic design principle of C# is that we tell you when things look wrong and force you to make them right -- which is not a basic design principle of, say, JavaScript. Its basic design principle is "muddle on through and try to do what the user meant". By placing more restrictions on what is correct syntax in C# we can better ensure that the intended semantics are expressed well in the program.

例如，如果我今天正在设计一个类似C＃的语言，那么我就不会有像这样的模糊语法：

For example, if I were designing a C#-like language today there is no way that I would have ambiguous syntaxes like:

class C : X , Y

或

... where T : X, Y

Y显然是一个接口。是X？我们不能在句法上告诉X是打算成为一个接口还是一个类。只要说这种模糊性就会使基本类型与接口等检测周期变得非常复杂。这将是更容易在所有有关如果它更冗长，因为它是在VB。

Y is clearly intended to be an interface. Is X? We can't tell syntactically whether X was intended to be an interface or a class. Suffice to say this ambiguity greatly complicates things like detecting cycles in base types vs interfaces and so on. It'd be much easier on all concerned if it were more verbose, as it is in VB.