Why are there no lifted short-circuiting operators on `bool?`?

Question

Why doesn't bool? support lifted && and ||? They could have lifted the true and false operators which would have indirectly added lifted && and ||.

The operators | and & are already lifted and implement the correct Three-valued logic. But of course they are not short circuiting like || and &&.

The question is why they decided not to lift those operators when creating the specification. So "It's like this because the spec says so" is no answer to the "why?".

When lifting true and false so that null is neither true nor false:

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

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

This would have resulted in && and || behaving just like their non short-circuiting counterparts. Except that false && anything and true || anything would short circuit (false and true are no compile time constants in these two examples).

This would work very similar to the DBBool example on MSDN.

I see no surprising or dangerous behavior introduced by lifting these operators. Did I miss something?

I have read another SO question on this, but found none of the answers satisfying.

---

Jeff Yates's answer shows a nice reason for why lifting the true/false operators isn't optimal, it doesn't explain why lifting && and || directly is bad. Since operator lifting is compiler magic that special cases Nullable<T> it doesn't need to follow the overloading rules for normal types and thus would be able to offer &&/|| without lifting true.

Answer 1

What you propose would create two different usage patterns for nullable types.

Consider the following code:

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)
{
}

For consistency in the usage of nullable types, it makes sense to not lift the true and false operators on bool. I don't know if this is the real reason why it wasn't done, but it makes sense to me.

Answer 2

Since you showed that lifting true and false is technically possible, there are only two possible answers to your question (with "they" being the people who wrote the compiler/spec):

1. It's an error in the spec, ie. they didn't think of this. (possible, but I doubt that)
2. They thought that lifting the short-circuiting operators is potentially error-prone. It could be the same way of reasoning as why C# is completely class based (no sole functions as in C++) or why a statement like if (myNullVar) { ... } (with myNullVar being a reference) doesn't work in C# (but it does in C/C++).

I think there's always a balance between making a programming language more powerful and making it less error-prone.

Update: Just for you interest, that's what the official documentation says:

This is not allowed because it is unclear what null means in the context of a conditional.

Answer 3

false && anything is the same as false. However if you expect false && anything to be true only if anything is false, then !anything is what you want.

Also, true || anything is the same as true. ...And I'm not sure how you could have it return false on any condition, as it would make no sense to have "this or that" return nothing!

... why adding additional weight to the condition when it's all clear and simple as it is?

I am not usually an adept of "because this is so", but I fail to see the advantage of adding such functionality.