关于c＃：为什么unsigned int不符合CLS？

Why are unsigned int's not CLS compliant?

为什么无符号整数不符合CLS？

我开始认为类型规范只是为了性能而不是为了正确性。

并非所有语言都具有无符号整数的概念。例如，VB 6没有无符号整数的概念，我怀疑这推动了VB7 / 7.1的设计者决定不实现(现在在VB8中实现)。

报价：

http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

The CLS was designed to be large enough to include the language
constructs that are commonly needed by developers, yet small enough
that most languages are able to support it. In addition, any language
construct that makes it impossible to rapidly verify the type safety
of code was excluded from the CLS so that all CLS-compliant languages
can produce verifiable code if they choose to do so.

更新：几年前我确实对此感到疑惑，虽然我不明白为什么UInt不会是类型安全可验证的，但我想CLS人员必须在某个地方有一个截止点，以确定什么是基线最小值支持的值类型数。此外，当您考虑将越来越多的语言移植到CLR的长期时，如果绝对没有概念，为什么迫使他们实施无符号整数以获得CLS合规性呢？

我怀疑，部分问题围绕这样一个事实：C中的无符号整数类型需要表现为抽象代数环的成员而不是数字[意味着，例如，如果无符号16位整数变量等于零，递减它需要产生65,535，如果它等于65,535然后递增它需要产生零。]有时候这种行为非常有用，但数字类型表现出这样的行为可能违背了某些语言的精神。我猜想省略无符号类型的决定可能早于支持已检查和未检查数字上下文的决定。就个人而言，我希望有无符号数和代数环的单独整数类型;将一元减号运算符应用于无符号32位数应产生64位有符号结果[否定零以外的任何内容将产生负数]但将一元减号应用于环类型应该在该环内产生加法逆。

在任何情况下，无符号整数不符合CLS的原因是Microsoft决定语言不必支持无符号整数以便被视为"CLS兼容"。

无符号的int在现实生活中不会获得那么多，但是如果有超过1种类型的int会给你带来痛苦，所以很多语言只会有一些内容。

CLS兼容旨在允许使用多种语言的类...

请记住，没有人会让您符合CLS。

您仍然可以在方法中使用无符号整数，或者作为私有方法的参数，因为它只是CLS兼容限制的公共API。

无符号整数不符合CLS，因为它们在某些语言之间不可互操作。