c# - C# 规范(团队？委员会？)是否考虑过这种对象创建语法？

Question

^{我以前从未发布过这种性质的问题，所以如果它不适合 SO，请不要太伤我的感情，我会删除它。}

为了让我关心的所有内容都尽可能靠近左边距，我一直希望我可以这样写:

DataService1.DataEntities dataEntities = new(constructorArg1, ...)

我认为另一个原因是我喜欢在赋值的右侧已经存在类型时使用 var 获得的额外屏幕空间，但我的大脑花了太多年时间寻找左侧的类型.话又说回来，被困在我的道路上并不是希望获得规范的好理由......

Answer 1

Has the C# design committee ever considered this object creation syntax?

是的，我们有。我们几年前考虑过。作为这一说法的证据，请在此处查看我文章的最后一段:

http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx

设计团队的共识是，这是一个“可有可无”的功能，但还不够引人注目，以至于值得为该功能的设计、实现、测试、记录和维护付出可观的成本。

我还注意到，我链接到的博客条目的评论对该功能非常负面；似乎很多人都觉得语法没有吸引力。这也是反对执行此功能的要点。

但是，如果您可以将它与促进不可变类型的简洁声明的其他语言功能结合起来，那么所提议的语法将变得特别好；如果我们在该语言的假设 future 版本中实现这样的功能，那么您提出的语法将变得更加引人注目。

我进一步注意到，我们通常抵制需要从“外部”到“内部”进行推理的特征；我们更喜欢那种由内而外的信息流。例如考虑这个问题:

M(new(blah));

假设 M 有两个重载，一个接受 C，一个接受 D。是“new C(blah)”还是“new D(blah)”？也可能是。现在我们必须分析两者!如果它们都有效，那么我们必须弄清楚哪个更好。

情况变得更糟。假设你有

M(new(new(blah)));

同样，M 接受 C 和 D，C 有两个接受 E 或 F 的构造函数，D 有两个接受 G 和 H 的构造函数。以下哪个:

M(new C(new E(blah)));
M(new C(new F(blah)));
M(new D(new G(blah)));
M(new D(new H(blah)));

被选中，为什么？

当您从外到内进行推理时，您很快就会陷入“组合爆炸”，其中要分析的案例数量在嵌套深度上变为 O(cⁿ)。

C# 确实以这种方式为 lambda 进行推理，相信我，这是编译器中最难实现高性能和正确性的部分之一。我们并不急于向构造函数添加类似的功能。如果我们要添加此语法，它可能仅限于通过分析变量声明或赋值表达式的左侧明确知道类型的场景。

(一如既往，我注意到埃里克在没有时间表或预算的未宣布和完全虚构的产品中对假设的 future 语言功能的思考仅用于娱乐目的，不应被解释为对任何特定 future 产品的 promise 任何特定的功能集。)