C＃不允许编写非成员函数，并且每个方法都应该是类的一部分。我当时认为这是所有CLI语言的限制。但是我错了，我发现C ++ / CLI支持非成员函数。编译后，编译器将使该方法成为某些未命名类的成员。
这是C ++ / CLI标准所说的，
[注：CLI将非成员函数视为某些未命名类的成员；但是，在C ++ / CLI源代码中，此类函数无法使用该类名明确限定。尾注] 未指定元数据中非成员函数的编码。[注意：这不会引起互操作问题，因为此类功能无法公开显示。尾注]
[注：CLI将非成员函数视为某些未命名类的成员；但是，在C ++ / CLI源代码中，此类函数无法使用该类名明确限定。尾注]
未指定元数据中非成员函数的编码。[注意：这不会引起互操作问题，因为此类功能无法公开显示。尾注]
所以我的问题是，为什么C＃不实现这样的东西？还是您认为不应该存在非成员函数，并且每个方法都应该属于某个类？
我的意见是拥有非成员函数支持，这有助于避免污染类的接口。
有什么想法吗..？
请参阅此博客文章：
http://blogs.msdn.com/ericlippert/archive/2009/06/22/why-doesn-tc-implement- top-level- methods.aspx
（…） 我被问到“为什么C＃不实现功能X？” 每时每刻。答案总是一样的：因为没有人设计，指定，实施，测试，记录和发布该功能。所有这六件事都是实现功能所必需的。所有这些都花费了大量的时间，精力和金钱。功能并不便宜，并且由于时间，精力和金钱预算有限，我们会尽力确保仅发布那些能给用户带来最大利益的功能。 我知道，这样的一般性回答可能无法解决特定问题。 在这种特殊情况下，过去明显的用户利益还不足以证明将要出现的语言复杂性。通过严格限制不同语言实体相互嵌套的方式，我们（1）将法律程序限制为通用，易于理解的样式，并且（2）可以定义可理解，可指定，可实现，可测试的“标识符查找”规则并记录在案。 通过限制方法主体始终位于结构或类内部，我们可以更轻松地推断调用上下文中使用的不合格标识符的含义；此类事物始终是当前类型（或基本类型）的可调用成员。 （…）
（…）
我被问到“为什么C＃不实现功能X？” 每时每刻。答案总是一样的：因为没有人设计，指定，实施，测试，记录和发布该功能。所有这六件事都是实现功能所必需的。所有这些都花费了大量的时间，精力和金钱。功能并不便宜，并且由于时间，精力和金钱预算有限，我们会尽力确保仅发布那些能给用户带来最大利益的功能。
我知道，这样的一般性回答可能无法解决特定问题。
在这种特殊情况下，过去明显的用户利益还不足以证明将要出现的语言复杂性。通过严格限制不同语言实体相互嵌套的方式，我们（1）将法律程序限制为通用，易于理解的样式，并且（2）可以定义可理解，可指定，可实现，可测试的“标识符查找”规则并记录在案。
通过限制方法主体始终位于结构或类内部，我们可以更轻松地推断调用上下文中使用的不合格标识符的含义；此类事物始终是当前类型（或基本类型）的可调用成员。
和此后续发布：
http://blogs.msdn.com/ericlippert/archive/2009/06/24/it-already-is-a- scripting- language.aspx
（…） 像所有设计决策一样，当我们面对许多相互竞争，令人信服，有价值和不可行的想法时，我们必须找到可行的折衷方案。除了 考虑所有可能性 外，我们不会这样做，这是我们在本例中所做的。
像所有设计决策一样，当我们面对许多相互竞争，令人信服，有价值和不可行的想法时，我们必须找到可行的折衷方案。除了 考虑所有可能性 外，我们不会这样做，这是我们在本例中所做的。
（强调原文）
