VB.NET vNext 中的迭代器，以及 C# 中迭代器的限制答案

【问题标题】：Iterators in VB.NET vNext, and limitations of iterators in C#VB.NET vNext 中的迭代器，以及 C# 中迭代器的限制
【发布时间】：2010-10-31 13:27:53
【问题描述】：

我刚刚在Async CTP website 上看到下一版本的 VB.NET 将具有迭代器。我猜他们包含了迭代器，因为重写过程类似于用于新 async/await 功能的过程。

但阅读解释该功能的文档后，我意识到 VB.NET 迭代器实际上将具有当今 C# 中不可用的功能，即：

这些是 C# 中的已知限制。有没有可能在 C# 5 中删除这些限制？如果没有，有什么理由可以在 VB.NET 而不是 C# 中完成？

【问题讨论】：

vb.net 一直是关于语言创新的，c# 虽然是一门不错的语言，但其核心并没有语言创新。基本上，vb.net 是一种更好的语言，如果你不接受它在 .net days.c 之前的坏名声。c# 没有 XML 文字，没有 xdocument 上的智能感知，更少的内置关键字超过 linq 到任何东西，没有 with 子句，更少可读，我应该继续吗？
C# 功能较少，人们喜欢这样，因为他们觉得使用一种语言创新较少的语言更聪明、更酷。他们购买 C/C++ 营销角度并使用 c#，因为他们认为它更酷，忘记了 vb6 != vb.net
问题不在于 VB.NET 比 C# 更好或更差，所以请不要开始拖钓……C# 的创新当然不比 VB 少。它从第 2 版（早于 VB 的 3 个版本）开始就有迭代器。 VB 中的 Lambda 表达式比 VS2008 中的 C# 受限得多。我个人认为 XML 文字是一件坏事™，而 VB 对我来说太冗长了。至于可读性，我发现 C# 更具可读性。这两种语言现在大多是等效的（功能上），所以你看，这主要是个人喜好问题......所以请避免这种无用的评论
顺便说一句，太糟糕了，我们不能对 cmets 投反对票...

【解决方案1】：

这些限制是否有可能在 C# 5 中被删除？

机会渺茫。我当然不会指望它。这些是“很高兴拥有”的功能，而不是“必须拥有”的功能，当您有大量工作要做时，“很高兴拥有”的功能有时会脱离计划，因为很好就像他们一样。

如果没有，有什么理由可以在 VB.NET 中而不是在 C# 中完成？

任何技术原因？不，当然有工程方面的原因。

通常情况下，作为实施特定功能的第二个团队是有益的。第二次实施的实施者可以利用从第一次尝试中获得的知识，而无需承担如此大的研发成本，同时不会产生任何维护或向后兼容性税。

VB 的好处是还没有这个功能，因此没有现有的数百万行用户代码需要 100% 向后兼容。这消除了相当大的成本负担。他们拥有一个包含错误报告、设计说明等的大型数据库，这些数据库在 C# 中拥有此功能已有八年了。

【讨论】：

谢谢 Eric，这当然是有道理的......我只是不想承认 VB 有比 C# 更多的东西 ;)
或者正如 Gilad Bracha 在 PDC 演讲中所说的那样：“一旦有了用户，一切就结束了”:-)
@Thomas：VB 也有 XML 文字。
Thomas，您不想在 C# 中使用 XML 文字吗？您不得在“企业环境”中工作。 ;) 对于我当前的项目，我们有一个专门的 VB.NET 项目，仅用于处理 XML 文件。尽管我更喜欢 C#，但 VB.NET 中的 XML 文字简直就是摇滚。不仅您可以更快地开发，XML 文字代码的可读性（因此可维护性）至少是 C# 中类似代码的 5 倍。对我来说，XML 文字比 try/catch 中的匿名迭代器块和迭代器块有用得多。你的旅费可能会改变。 Eric，C# 中对 XML 文字的需求如何？
这还不是全部，如果您拥有正确的 XML 架构，您甚至可以获得 Intellisense 支持。此屏幕截图显示了针对 Office XML 的 Intellisense。 imgur.com/38PJ3 我无法告诉你我节省了多少时间，这要归功于 Intellisense。同样，C# 中的 XElement 没有任何 Intellisense 支持。我真的强烈建议您在实际代码中使用 XML Literals，然后再打折。一旦你尝试过，你就永远不想用任何其他语言进行 XML 操作，我敢打赌。