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()有什么坏处，关于这个建议如果各位有其他想法，不妨留个言?
