c# - 从 char 到单字符串的隐式转换

Question

首先:我知道如何解决这个问题。我不是在寻找解决方案。我对导致一些隐式转换而没有导致其他隐式转换的设计选择背后的推理很感兴趣。

今天我在我们的代码库中遇到了一个小但有影响的错误，其中 int常量被初始化为 char表示相同的数字。这会导致 ASCII char的转换到 int .像这样的东西:

char a = 'a';
int z = a;
Console.WriteLine(z);    
// Result: 97

我很困惑为什么 C# 会允许这样的事情。在四处搜索后，我发现了以下 SO 问题，并由 Eric Lippert 本人回答: Implicit Type cast in C#

摘录:

However, we can make educated guesses as to why implicit char-to-ushort was considered a good idea. The key idea here is that the conversion from number to character is a "possibly dodgy" conversion. It's taking something that you do not KNOW is intended to be a character, and choosing to treat it as one. That seems like the sort of thing you want to call out that you are doing explicitly, rather than accidentally allowing it. But the reverse is much less dodgy. There is a long tradition in C programming of treating characters as integers -- to obtain their underlying values, or to do mathematics on them.

我同意其背后的推理，尽管 IDE 提示会很棒。但是，我还有另一种情况，隐式转换突然不合法:

char a = 'a';
string z = a; // CS0029 Cannot implicitly convert type 'char' to 'string'

这种转换以我的拙见，非常合乎逻辑。它不会导致数据丢失，作者的意图也很明确。同样在我阅读了 char 上的其余答案之后至 int隐式转换，我仍然没有看到任何理由为什么这不应该是合法的。

所以这让我想到了我的实际问题:

C# 设计团队有什么理由不实现来自 char 的隐式转换？到 string ，虽然它的外观看起来如此明显(尤其是将它与 char 到 int 的转换进行比较时)。

Answer 1

首先，当有人问“为什么不呢？”时，我总是说。关于 C# 的问题:设计团队不必提供不做功能的理由。功能需要花费时间、精力和金钱，而您所做的每一个功能都需要花费时间、精力和金钱才能获得更好的功能。

但我不想直接拒绝这个前提；这个问题可以更好地表述为“这个提议的功能的设计优点和缺点是什么？”

这是一个完全合理的功能，并且有一些语言允许您将单个字符视为字符串。 (蒂姆在评论中提到了 VB，Python 也将字符和单字符字符串视为可互换的 IIRC。我相信还有其他的。)但是，如果我推荐了这个功能，我会指出一些缺点:

这是一种新的拳击转换形式。字符是廉价的值类型。字符串是堆分配的引用类型。装箱转换可能会导致性能问题并产生收集压力，因此有一个论点认为它们应该在程序中更加可见，而不是不那么可见。

该功能不会被视为“字符可转换为单字符字符串”。会被用户感知为“字符是一个字符串”，现在问很多敲门问题是完全合理的，例如:可以拨打.Length在字符上？如果我可以将字符传递给需要 string 的方法，我可以将一个字符串传递给一个需要 IEnumerable<char> 的方法。 , 我可以通过一个 char到一个需要 IEnumerable<char> 的方法?这似乎……很奇怪。我可以打电话Select和 Where在字符串上；我可以在字符上吗？这似乎更奇怪。提议的功能所做的就是移动您的问题；如果实现了，您现在会问“为什么我不能在字符上调用 Select？”或者一些这样的事情。

现在将前两点结合在一起。如果我将字符视为单字符字符串，并将字符转换为对象，那么我得到的是盒装字符还是字符串？

我们还可以进一步概括第二点。字符串是字符的集合。如果我们要说一个字符可以转换为字符集合，为什么要停止使用字符串呢？为什么不说一个字符也可以用作 List<char> ?为什么要停止使用 char ?我们应该说 int可转换为 IEnumerable<int> ?

我们可以进一步概括:如果从 char 到字符串中的字符序列有明显的转换，那么也有从 char 到 Task<char> 的明显转换。 -- 只需创建一个返回字符的已完成任务 -- 并转到 Func<char> -- 只需创建一个返回字符的 lambda -- 然后到 Lazy<char> ，并致 Nullable<char> -- 哦，等等，我们确实允许转换为 Nullable<char> . :-)

所有这些问题都是可以解决的，有些语言已经解决了。这不是问题。问题是:所有这些问题都是语言设计团队必须识别、讨论和解决的问题。语言设计的基本问题之一是 这个功能应该有多普遍？ 在两分钟内，我已经从“字符可转换为单字符串”变为“基础类型的任何值都可转换为一元类型的等效值”。对于这两个特征以及一般性范围内的其他各种点，都有一个论据。如果你让你的语言特性过于具体，它就会变成大量的特殊情况，它们之间的交互很差。如果你让它们太笼统，那么，我猜你有 Haskell。 :-)

假设设计团队对功能得出一个结论:所有这些都必须写在设计文档和规范中，并且必须编写代码和测试，哦，我有没有提到过更改可转换性规则，某人的重载解析代码中断了？您在第一个版本中确实必须正确处理可转换性规则，因为稍后更改它们会使现有代码更加脆弱。存在真正的设计成本，如果您在版本 8 而不是版本 1 中进行此类更改，那么对真实用户来说也会有实际成本。

现在比较这些缺点——我敢肯定还有更多我没有列出——和优点。好处非常小:您可以避免一次拨打 ToString或 + ""或者你做什么来显式地将字符转换为字符串。

这甚至不足以证明设计、实现、测试和向后兼容破坏成本的合理性。

就像我说的，这是一个合理的特性，如果它出现在语言的第 1 版中——没有泛型，或者安装了数十亿行代码——那么它会更容易销售。但是现在，有很多功能可以用更小的成本获得更大的 yield 。