C#如果把A.new()编译成new A()

缘由

对于初次接触某个第三方库的C#开发者，假如要调用里面一个方法，发现需要一个A类型的实例作为参数，怎么获得这个实例呢?

我想大多数人会先尝试new A吧:

如果没有，可能会尝试输入A.看看有没可能的构造方法:

要如果还没有，那一般要通过其他方式获得了（子类、其他方法的返回结果等）。就此打住，因为后面的不在此文讨论范围。

我就郁闷了，为何要我输入一次new之后发现没有，然后再次输入A.呢？

我指的是，最好让C#编译器支持这样的语法糖：A.new() 跟new A()等价。

本文不适合的阅读对象

文档帝：万事必先看文档的人，本文说明的东西与你无关。
键盘帝：不使用VS或者类似的智能提示的用户，本文说明的东西对你没什么影响。

好处是什么？

“你不觉得输入一次new A之后删掉再输入A.这个过程很傻吗？”

只需输入A.即可知道是否有构造函数，类似A.create这样的工厂方法，或者像A.instance这样的单例对象，列在一起更方便对比。

另外一个好处是，A.new 可以通过匹配参数类型来赋值给一个委托实例(Delegate)。

有什么可能出现的问题?

“万一用户想创建一个名为new的方法怎么办？”

毫无疑问，这种方式可能引起误解，以为这是一个静态方法，相当于类空间的命名被污染了。不过这种的说法是不成立的。

首先，假设A是个类型，当看到A.x()的时候，你觉得这是什么？事实上，你完全不能确定他是啥，可能是一个静态方法，也可能是静态属性，还可能是静态字段。所以，A.new()到底是什么本身就没可误解的地方。

其次，当用户想定义一个名为new的方法，实际上也是不可行的：

因为new是个关键字，要作为方法名的话，前面需要加@

调用时@也是不可省略的

所以，A.new()本来就是不能编译通过的，跟现有语法体系没有冲突。

对比起来，C#的自动属性才是真正的“污染类空间命名”，而附加属性也一定程度影响开发者的惯性思维，A.new()比起这些真的是小巫见大巫，语法糖而已。

“反射的时候，会有问题吗？”

我觉得不会，Type.GetMethod的时候，本来就不包含构造函数。抽象类、接口、枚举这些东西，有new没new本身就是规则定好的，跟现有语法不混淆。

至于各种IDE的智能提示，作为规则支持就是了。

“假如A的名字好长好长，就没new A()方便”

是的，当输入B.f(new空格后，可以看到A在列表里直接选择回车，这样敲的字符数是很少的。所以，new A()的方式完全可以保留。另外，提供一个智能提示，还记得事件绑定的那个snippet吗？

待补充

到此，我还是没想到把A.new()编译成new A()有什么坏处，关于这个建议如果各位有其他想法，不妨留个言?