我对“5”的看法 == 5

每个程序员都应该对像 "5" == 5 这样的表达式的结果有自己的看法，甚至可能猜测他们最熟悉的编程语言中的答案是什么。在我看来，SQL 是正确的。例如，我们在 Google BigQuery 中得到以下内容。 SELECT "5" = 5-- 没有匹配的运算符 = 参数类型的签名：STRING、INT64。支持的签名：ANY = ANY at [1:8] 这是一个很好的安全早期错误，可以防止很多令人困惑的数据处理错误。这在相关示例中可能更清楚。 SELECT "5" IN (1, 2, 3)-- 对于参数类型文字 STRING 和 {INT64} 在 [1:12] 处的运算符 IN 没有匹配的签名在这种情况下：用户很可能是指 SELECT 5 IN (1 , 2, 3)，即检查一个整数是否在给定的整数集合中。并且用户实际上不太可能是指 SELECT "5" IN (1, 2, 3)。通过简单的类型检查，第二种形式在 SQL 中永远不会为真，因此禁止它很有用。违反预期的行为会被发现，因此很容易发现和避免。为了好玩，从记忆中，在 Python3 中计算表达式 "5" == 5 的结果是什么？

事实证明它是 False，这在通用编程语言中很有用且易于理解。 Python 处理异构列表和集合。因此，给定语言上下文，{1, 2, 3} 中的 "5" == 5 和 "5" 是合理的表达式。 R 是一种我喜欢并经常使用的语言。哎呀，我什至写了一本关于使用 R 工作的书，我为此感到非常自豪。但是，我无法为“5”==5 的 R 返回值辩护。结果证明这是正确的。当然，人们可以猜测哪种隐式转换支持这一点，但 R 不是一种字符串和数字通常等效的语言。然而，我们有 5 %in% c("5") 评估为 TRUE。 R 主要强制执行同构类型，但它通过安静的隐式类型转换（一种不断提供的错误礼物）来实现。一个消息灵通的 R 用户期望 c(5, "5") 是一个字符串向量；我不太相信许多人期望“5” == 5 评估为 TRUE。人们会期望相等的值总是可以支持相同的操作。然而，在 R 中，5 + 1 是一个合理的表达方式，而“5” + 1 则不是。所以，我发现很难说 5 和“5”是等价的。