Do short-circuiting operators || and && exist for nullable booleans? The RuntimeBinder sometimes thinks so

Question

I read the C# Language Specification on the Conditional logical operators || and &&, also known as the short-circuiting logical operators. To me it seemed unclear if these existed for nullable booleans, i.e. the operand type Nullable<bool> (also written bool?), so I tried it with non-dynamic typing:

bool a = true;
bool? b = null;
bool? xxxx = b || a;  // compile-time error, || can't be applied to these types

That seemed to settle the question (I could not understand the specification clearly, but assuming the implementation of the Visual C# compiler was correct, now I knew).

However, I wanted to try with dynamic binding as well. So I tried this instead:

static class Program
{
  static dynamic A
  {
    get
    {
      Console.WriteLine("'A' evaluated");
      return true;
    }
  }
  static dynamic B
  {
    get
    {
      Console.WriteLine("'B' evaluated");
      return null;
    }
  }

  static void Main()
  {
    dynamic x = A | B;
    Console.WriteLine((object)x);
    dynamic y = A & B;
    Console.WriteLine((object)y);

    dynamic xx = A || B;
    Console.WriteLine((object)xx);
    dynamic yy = A && B;
    Console.WriteLine((object)yy);
  }
}

The surprising result is that this runs without exception.

Well, x and y are not surprising, their declarations lead to both properties being retrieved, and the resulting values are as expected, x is true and y is null.

But the evaluation for xx of A || B lead to no binding-time exception, and only the property A was read, not B. Why does this happen? As you can tell, we could change the B getter to return a crazy object, like "Hello world", and xx would still evaluate to true without binding-problems...

Evaluating A && B (for yy) also leads to no binding-time error. And here both properties are retrieved, of course. Why is this allowed by the run-time binder? If the returned object from B is changed to a "bad" object (like a string), a binding exception does occur.

Is this correct behavior? (How can you infer that from the spec?)

If you try B as first operand, both B || A and B && A give runtime binder exception (B | A and B & A work fine as everything is normal with non-short-circuiting operators | and &).

(Tried with C# compiler of Visual Studio 2013, and runtime version .NET 4.5.2.)

Heckman

There are no instances of Nullable<Boolean> involved at all, only boxed booleans treated as dynamic -- your test with bool? is irrelevant. (Of course, this is not a full answer, only the germ of one.) – Ashley

Have you experimented with x.HasValue && x.Value || y.HasValue && y.Value? You need to be explicit, one way or another, about how you want nulls handled. – Venditti

The A || B makes a certain amount of sense, in that you don't want to evaluate B unless A is false, which it's not. So you never know the type of the expression, really. The A && B version is more surprising - I'll see what I can find in the spec. – Mallard

@JeroenMostert: Well, unless the compiler were to decide that if the type of A is bool and the value of B is null, then a bool && bool? operator might be involved. – Mallard

Interestingly, it looks like this has exposed a compiler or spec bug. The C# 5.0 specification for && talks about resolving it as if it were & instead, and specifically includes the case where both operands are bool? - but then the next section it refers to doesn't handle the nullable case. I could add a sort of answer going into more detail on that, but it wouldn't fully explain it. – Mallard

I've emailed Mads about the spec problem, to see whether it's just an issue in how I'm reading it... – Mallard

Answer 1

First of all, thanks for pointing out that the spec isn't clear on the non-dynamic nullable-bool case. I will fix that in a future version. The compiler's behavior is the intended behavior; && and || are not supposed to work on nullable bools.

The dynamic binder does not seem to implement this restriction, though. Instead, it binds the component operations separately: the &/| and the ?:. Thus it's able to muddle through if the first operand happens to be true or false (which are boolean values and thus allowed as the first operand of ?:), but if you give null as the first operand (e.g. if you try B && A in the example above), you do get a runtime binding exception.

If you think about it, you can see why we implemented dynamic && and || this way instead of as one big dynamic operation: dynamic operations are bound at runtime after their operands are evaluated, so that the binding can be based on the runtime types of the results of those evaluations. But such eager evaluation defeats the purpose of short-circuiting operators! So instead, the generated code for dynamic && and || breaks the evaluation up into pieces and will proceed as follows:

• Evaluate the left operand (let's call the result x)
• Try to turn it into a bool via implicit conversion, or the true or false operators (fail if unable)
• Use x as the condition in a ?: operation
• In the true branch, use x as a result
• In the false branch, now evaluate the second operand (let's call the result y)
• Try to bind the & or | operator based on the runtime type of x and y (fail if unable)
• Apply the selected operator

This is the behavior that lets through certain "illegal" combinations of operands: the ?: operator successfully treats the first operand as a non-nullable boolean, the & or | operator successfully treats it as a nullable boolean, and the two never coordinate to check that they agree.

So it's not that dynamic && and || work on nullables. It's just that they happen to be implemented in a way that is a little bit too lenient, compared with the static case. This should probably be considered a bug, but we will never fix it, since that would be a breaking change. Also it would hardly help anyone to tighten the behavior.

Hopefully this explains what happens and why! This is an intriguing area, and I often find myself baffled by the consequences of the decisions we made when we implemented dynamic. This question was delicious - thanks for bringing it up!

Mads

Dobbins

I can see that these short-circuiting operators are special, since with dynamic binding we are not really allowed to know the type of the second operand in the case where we short-circuit. Maybe the spec should mention that? Of course, since everything inside a dynamic is boxed, we cannot tell the difference between a bool? which HasValue, and a "simple" bool. – Heckman

Answer 2

Is this correct behavior?

Yes, I'm pretty sure it is.

How can you infer that from the spec?

Section 7.12 of C# Specification Version 5.0, has information regarding the conditional operators && and || and how dynamic binding relates to them. The relevant section:

If an operand of a conditional logical operator has the compile-time type dynamic, then the expression is dynamically bound (§7.2.2). In this case the compile-time type of the expression is dynamic, and the resolution described below will take place at run-time using the run-time type of those operands that have the compile-time type dynamic.

This is the key point that answers your question, I think. What is the resolution that happens at run-time? Section 7.12.2, User-Defined conditional logical operators explains:

• The operation x && y is evaluated as T.false(x) ? x : T.&(x, y), where T.false(x) is an invocation of the operator false declared in T, and T.&(x, y) is an invocation of the selected operator &
• The operation x || y is evaluated as T.true(x) ? x : T.|(x, y), where T.true(x) is an invocation of the operator true declared in T, and T.|(x, y) is an invocation of the selected operator |.

In both cases, the first operand x will be converted to a bool using the false or true operators. Then the appropriate logical operator is called. With this in mind, we have enough information to answer the rest of your questions.

But the evaluation for xx of A || B lead to no binding-time exception, and only the property A was read, not B. Why does this happen?

For the || operator, we know it follows true(A) ? A : |(A, B). We short circuit, so we won't get a binding time exception. Even if A was false, we would still not get a runtime binding exception, because of the specified resolution steps. If A is false, we then do the | operator, which can successfully handle null values, per Section 7.11.4.

Evaluating A && B (for yy) also leads to no binding-time error. And here both properties are retrieved, of course. Why is this allowed by the run-time binder? If the returned object from B is changed to a "bad" object (like a string), a binding exception does occur.

For similar reasons, this one also works. && is evaluated as false(x) ? x : &(x, y). A can be successfully converted to a bool, so there is no issue there. Because B is null, the & operator is lifted (Section 7.3.7) from the one that takes a bool to one that takes the bool? parameters, and thus there is no runtime exception.

For both conditional operators, if B is anything other than a bool (or a null dynamic), runtime binding fails because it can't find an overload that takes a bool and a non-bool as parameters. However, this only happens if A fails to satisfy the first conditional for the operator (true for ||, false for &&). The reason this happens is because dynamic binding is quite lazy. It won't try to bind the logical operator unless A is false and it has to go down that path to evaluate the logical operator. Once A fails to satisfy the first condition for the operator, it will fail with the binding exception.

If you try B as first operand, both B || A and B && A give runtime binder exception.

Hopefully, by now, you already know why this happens (or I did a bad job explaining). The first step in resolving this conditional operator is to take the first operand, B, and use one of the bool conversion operators (false(B) or true(B)) before handling the logical operation. Of course, B, being null cannot be converted to either true or false, and so the runtime binding exception happens.

Amata

No surprise that with dynamic the binding happens at run-time using the actual types of the instances, not the compile-time types (your first quote). Your second quote is irrelevant since no type here overloads the operator true and operator false. An explicit operator returning bool is something else than operator true and false. It is hard to read the spec in any way that allows A && B (in my example), without also allowing a && b where the a and b are statically typed nullable booleans, i.e. bool? a and bool? b, with binding at compile-time. Yet that is disallowed. – Heckman

Answer 3

The Nullable type does not define Conditional logical operators || and &&. I suggest you following code:

bool a = true;
bool? b = null;

bool? xxxxOR = (b.HasValue == true) ? (b.Value || a) : a;
bool? xxxxAND = (b.HasValue == true) ? (b.Value && a) : false;

Tolerance