19

为什么不bool?支持解除&&和||？他们本可以解除trueandfalse运算符，而这会间接添加解除&&and ||。

运算符|和&已经被解除并实现了正确的三值逻辑。||但是，它们当然不会像和那样短路&&。

问题是为什么他们决定在创建规范时不取消这些运算符。所以“就像这样，因为规范是这样说的”并不能回答“为什么？”。

举起时，true既不是，也不是：falsenulltruefalse

public static bool operator true(bool? x) 
{
    return x.HasValue && x.Value
}

public static bool operator false(bool? x) 
{
  return x.HasValue && !x.Value
}

这将导致&&和||行为就像它们的非短路对应物一样。除了false && anythingandtrue || anything会短路（false并且true在这两个示例中没有编译时间常数）。

这与MSDN 上的 DBBool 示例非常相似。

我没有看到解除这些操作员带来的令人惊讶或危险的行为。我错过了什么？

我已经阅读了另一个关于此的 SO 问题，但没有一个令人满意的答案。

trueJeff Yates 的回答显示了为什么提升/运算符不是最佳的一个很好的理由false，它没有解释为什么提升&&和||直接是不好的。由于运算符提升是特殊情况下的编译器魔法，Nullable<T>因此它不需要遵循普通类型的重载规则，因此能够提供&&/||不提升true。

4

3 回答 3

4

由于您展示了提升true并且false在技术上是可行的，因此您的问题只有两个可能的答案（“他们”是编写编译器/规范的人）：

  1. 这是规范中的错误，即。他们没有想到这一点。（可能，但我怀疑）
  2. 他们认为解除短路运算符可能容易出错。这可能与为什么 C# 完全基于类（没有 C++ 中的唯一函数）或为什么像if (myNullVar) { ... }（myNullVar作为引用）这样的语句在 C# 中不起作用（但在 C/C++ 中起作用）的推理方式相同。

我认为在让编程语言更强大和更不容易出错之间总是存在平衡。

更新：只是为了你的兴趣，这就是官方文档所说的：

这是不允许的，因为不清楚 null 在条件上下文中的含义。

于 2011-06-13T06:40:49.507 回答
4

您的建议将为可空类型创建两种不同的使用模式。

考虑以下代码：

bool? a = null;

// This doesn't currently compile but would with lifted true/false operators.
if (a)
{
}

// Whereas this provides a consistent use of nullable types.
if (a ?? false)
{
}

true为了保持可空类型使用的一致性，不要在 . 上取消andfalse运算符是有意义的bool。我不知道这是否是它没有完成的真正原因，但这对我来说很有意义。

于 2011-03-05T17:26:54.687 回答
0

false && anything是一样的false。但是，如果您仅在为假时才期望false && anything为真，那么这就是您想要的。anything!anything

此外，true || anything与 相同true。...而且我不确定如何让它在任何情况下都返回 false，因为让“这个或那个”什么都不返回是没有意义的！

......为什么在一切都清楚和简单的情况下增加额外的重量？

我通常不擅长“因为这是这样”，但我看不到添加此类功能的优势。

于 2011-03-05T14:29:24.390 回答