C# 静态扩展方法与Roslyn项目

人们已经注意到（并且非常正确地注意到，.NET中的扩展方法只是对实例变量的静态方法调用的语法糖

然而，关于，我想知道为什么在语言规范中省略了静态访问的扩展方法

作为一名.NET（C#）开发人员，我也是一名JavaScript开发人员，您可以在JavaScript中对静态方法扩展进行等效建模——因此，我的理由是深入研究这一论点。（我很清楚.NET和JavaScript是两种截然不同的语言！）

让我们检查扩展方法的语法及其编译方式：

public static string Hash(this string value)
{
    // some logic here...
}

string x = "Hello World";

x.Hash();

编译成

public static string Hash(string value)
{
    // some logic here...
}

string x = "Hello World";

Hash(x);

如果尝试为静态类型创建变量

class MyClass
{
    Console c; // error!
}

你不能

如果尝试将静态类型作为方法参数传递

public void DoThis(Console c) // error!
{
}

你不能

因此，这定义了语言规范的局限性，但是就扩展方法而言，我可以看到实现是沿着这些路线的

public static void WriteLineInGreen(static Console c, string formatString, params object[] args)
{
    c.ForeGround = ConsoleColor.Green;
    c.WriteLine(formatString, args);
}

Console.WriteLineInGreen("Hello World {0}, {1}, {2}", ":-)", 1234, true);

好吧，这是不可能的…为什么我还在问？回答…“罗斯林计划”。您认为这是我们可能会看到的，以及将在ProjectRoslyn中实现的所有其他语言规范更改吗

---

编辑任何对Roslyn语言扩展感兴趣的人都应该注意这一点：

您不能创建静态类型的实例<代码>变量c=新控制台（）不起作用。因此，不能使用静态类型的参数。在

控制台c

中，

c

是什么？建议的静态类型扩展方法的语法必须如下所示：

public static void WriteLineInGreen(static Console, string formatString,
                                    params object[] args)
{
    Console.ForeGround = ConsoleColor.Green;
    Console.WriteLine(formatString, args);
}

我认为与Roslyn相关的语言规范变化是由于在Roslyn工作时发现语言规范不一致和不准确。在我看来，任何新的C语言特性都与Roslyn有关似乎不是很合理

更新：嗯，我在最后一点上错了。正如@svick在他的评论中指出的，新编译器更好的结构使得实现语言更改更容易

---

另一个重要原因是语言和编译器开发已经成为开源。Microsoft邀请社区参与。（请参阅：）

您看到这个了吗？-根据我在这里看到的，在我看来，Roslyn将把语言扩展到“不一致性”之外。“在我看来，任何新的C#语言功能都与Roslyn相关似乎不是很合理。”它们是。据报道，在旧的编译器中，很难对语言进行更改。有了Roslyn编译器，这就容易多了，这就是为什么C#6.0将包含大量的小更改（以前不值得这么做）。在C#和VB.NET之间曾经出现过一些情况，规范阻止了事后看来应该是有效的代码。而不是千方百计重新实施该区块，我们刚刚删除了规范中令人不快的部分。在阅读了这些评论后，我得出结论，Roslyn是新语言功能的催化剂，有些功能是由于删除了一些多余的限制。这个问题似乎离题了，因为它是关于预测未来的。你似乎在寻找关于Roslyn的讨论。我认为这是正确的地方，不是这样。一般来说，“为什么语言X不实现特性Y？”不是好问题。C#3中增加了扩展方法。Eric Lippert表示，C#团队在该版本中有大量工作要做，LINQ不需要的一切都被削减了。至于C#6，静态扩展方法不在列表中。实际上，Eric已经回答了上的一个问题。直接回答您的问题：“Q：我想知道为什么在语言规范中省略了静态访问的扩展方法？”。。。答案是没有理由。我们并不是一开始就假设我们会添加任何人都能想到的所有语言扩展，然后再考虑排除它们的原因。相反，我们故意决定要包含哪些功能，并且我们有理由包含它们。你建议的那个不在我们决定包括的范围之内。