[Proposal]: Short-circuit null-conditional for bool types.

[tacosontitan]

Short-Circuit Null-Conditional for bool types.

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

This proposed feature is meant to allow for short-circuit logical evaluations that result in a bool instead of bool?. Currently, the existing null-conditional short-circuits to evaluate to null if the identifier preceding it is null. This proposal recommends compile time evaluation of the property itself to derive a true or false reading instead of null using a new operator such as ??., or by adding functionality to the existing null-conditional operator ?..

Motivation

Developers consistently have to check objects for a null value prior to utilizing any members contained within. The proposed operator simplifies bool based logical evaluations from:

if (someObject?.SomeBoolProperty == true)

to

if (someObject??.SomeBoolProperty)

Detailed design

Think of the operator like the and-also, or-else, and traditional null-conditional operators. These all short circuit on the first operation that would fail to result as a true evaluation. The same would hold true for the proposed operator, for example:

MyCustomType someObject = new MyCustomType() { SomeProperty = true };
if (someObject??.SomeProperty)

The above snippet would result in true because someObject is non-null, and SomeProperty is set to true. But in this case:

MyCustomType someObject = null;
if (someObject??.SomeProperty)

This evaluation should result in false because someObject is null which means that SomeProperty cannot be true with 100% certainty.

Now let's say that SomeProperty is of type int instead of bool. The logical evaluation used in both examples above would fail to compile because the if statement requires bool as a result. In order for compilation to work an implementing developer would have to fully expand out the result:

if (someObject??.SomeProperty == 1)

Which is where I come to the drawbacks.

Drawbacks

I'm not sure how long this would take to implement, and it doesn't save developers a whole lot of time so it's not as useful as many other proposals. In a nutshell, potentially too much work for too little reward. This is truly only beneficial for bool properties and thus making it only minimally impactful to development as a whole.

Alternatives

In my opinion the alternative is to just be direct with the logical evaluation's expectations and use the null-conditional (?.) already available:

if (someObject?.SomeProperty == true)

We could also simply update the existing null-conditional to result the same way and force direct checks for null on bool evaluations:

MyCustomType someObject = null;
if (someObject?.SomeProperty)

In this alternative, the null-conditional operator would still compile and would understand that the developer intends for the result to be a bool and thus, based on the understanding that since someObject is null, SomeProperty could never be true and thus the evaluation results to false. Likewise when utilizing the not operator in conjunction with it:

if (!someObject?.SomeProperty)

In this case, the same is still true. someObject is null, therefore SomeProperty can never be true and thus the evaluation results in true because !false is true.

Unresolved questions

How would this work at runtime with dynamic objects or with var?

Design meetings

[JustNrik]

This shouldn't be any hard to implement, VB already does this by simply calling GetValueOrDefault(). I'm actually curious about why c# hasn't implemented this after decades...

[CyrusNajmabadi]

To be very explicit on this: because we (the members of the LDM) do not think such an implicit behavior is a good idea. We view it as a negative for the C# language, so we have explicitly made the express decision to not support this :)

[HaloFour]

@JustNrik

It was an intentional design decision, C# expects the developer to be explicit about their conditions. null is not false.

https://ericlippert.com/2012/04/12/null-is-not-false-part-two/

[JustNrik]

@JustNrik

It was an intentional design decision, C# expects the developer to be explicit about their conditions. null is not false.

https://ericlippert.com/2012/04/12/null-is-not-false-part-two/

That doesn't make any sense, if evaluates for true, not for false. if (bool?) should be possible since if is supposed to evaluate if it's true, it doesn't evaluate if it's false.

[CyrusNajmabadi]

FYI, i moved this to be a disussion.

As mentioned above, this was very intentional on our part. if/else is known by people to apply two-value boolean logic. We felt it was too confusing as to what should happen if you used a bool? in the condition. For example, some people wanted:

if (nBool)
{
    // run if true
}
else
{
   // run if not true
}

while some wanted:

if (nBool)
{
    // run if true
}
else
{
   // run if false
}

We considered constructs like:

if (nBool)
{
   // if true
}
else
{
   // if false
}
null
{
  // if null
}

But decided it was too niche to add. It was also unnecessary with the work we did with switch statements/expressions where you can do:

nBool switch
{
    true => ...,
    false => ...,
    null => ...,
};

[HaloFour]

The blog post explains exactly where that reasoning breaks down. In either case the C# team decided very explicitly to not treat bool? implicitly as bool. It has nothing to do with whether or not it would be technically difficult to implement.

[tacosontitan]

Thank you for the clarification, and I can easily see the reasoning for it. 😀