为什么数组初始化总是求助于int？

Question

阅读所有可能的C#数组初始化语法我想知道为什么C#总是推断int/Int32一个较小数据类型的数组,例如byte或者short就足够了.

new[] { 30, 130, 230 } // sbyte[] suffices but becomes int[]
new[] { -1, 125, -119 } // sbyte[] suffices  but becomes int[]
new[] { -31647, -1337, 23456} // short suffices but becomes int[]

在引用的问题中,Eric Lippert表示使用了"最佳类型" - 见下文,但int最好的类型是怎样的？如果我们想要矫枉过正,为什么不使用long呢？

数组元素的类型是通过计算具有类型的所有给定元素的最佳类型(如果有的话)来推断的.所有元素必须可以隐式转换为该类型.

我怀疑处理8位或16位数据类型可能比32位结构更快,例如当使用SIMD时,其中四个byte实例可以适合一个寄存器空间int/Int32.我知道JIT编译器没有(广泛地)使用SSE指令,但是" int无处不在"的这种使用确保了当JIT编译器将包含这样的优化时它将没有多大帮助.

有人可以详细说明这些事实,并告诉它为什么总是采取行动int？

//编辑// 我真的不关心那些规定没有前缀的文字应该被认为是规范的规范int.重新解释一下这个问题:

为什么使用的数据类型比需要的大？为什么规范对文字有这个规则？ 有什么好处,因为巨大的缺点是远离未来(SIMD)的优化.

Answer 1

为什么使用的数据类型比需要的大？

您在整数中进行计算并且可以保证结果适合字节或短的业务线应用程序的数量非常小.整数计算结果适合int的业务线应用程序的数量是巨大的.

为什么规范对文字有这个规则？

因为这是一个非常明智的规则.它是一致的,清晰的和可理解的.它在许多语言目标之间做出了很好的折衷,例如合理的性能,与现有非托管代码的互操作性,对其他语言用户的熟悉程度,以及将数字视为数字而不是位模式.绝大多数C#程序使用数字作为数字.

有什么好处,因为巨大的缺点是远离未来(SIMD)的优化.

我向你们保证,千万名C#程序员不会将"利用SIMD优化的难度"列为C#数组类型推理语义的"巨大缺点".事实上你可能是唯一一个.它当然不会发生在我身上.如果您是那种非常关心它的人,那么在数组初始化程序中创建类型清单.

C#的设计并不是为了将未来可能发明的机器的最后一盎司性能所取代,特别是在涉及类型推断时并不是这样设计的.它旨在提高业务线开发人员的工作效率,而业务线开发人员并不认为columnWidths = new [] { 10, 20, 30 };是一个字节数组.