Using nullable checks and bool methods on an object not generating consistent code

[ezgambac]

I've recently noticed that comparing for == false and != true doesn't mean the same when using the ? accessor for possibly null objects.

Given the following example:

public class C {
    public void M(Dictionary<string, string> a) {
        if(a?.TryGetValue("h", out var _) == true) {
            Console.WriteLine("Hello");
        }
        if(a?.TryGetValue("h", out var _) != true) { // 1
            Console.WriteLine("Hello");
        }
        if(a?.TryGetValue("h", out var _) == false) { // 2
            Console.WriteLine("Hello"); 
        }
    }
}

The normal interpretation would be that 1 and 2 should be interchangeable, as in one case we are checking for !true and the other for false, which mean the same.
However, the code gets translated like this:

public class C
{
    [System.Runtime.CompilerServices.NullableContext(1)]
    public void M(Dictionary<string, string> a)
    {
        string value;
        if (a != null && a.TryGetValue("h", out value))
        {
            Console.WriteLine("Hello");
        }
        if (a == null || !a.TryGetValue("h", out value)) // 1
        {
            Console.WriteLine("Hello");
        }
        if (a != null && !a.TryGetValue("h", out value)) // 2
        {
            Console.WriteLine("Hello");
        }
    }
}

From a simple glance, 1 and 2 are actually very different. 1 is checking for either a is null or !a.TryGetValue, whereas 2 is checking for a is not null and !a.TryGetValue.
It is not obvious at all that changing the comparison from != true to == false would cause this, as in general they would be expected to mean the same.

So, a?.TryGetValue("h", out var _) == false should be true if a is null (TryGetValue should be false in this case by default, as there is no dictionary, which means no result, ergo false), or a is not null and !a.TryGetValue is true, like in scenario 1.

Please make the behavior consistent so that != true and == false generate the same code, and generate the code in scenario 1.
This is a not obvious foot gun which causes us to not use ? for checking negatives, as it's not expected that == false and != true behave differently in general, so we instead manually write the code for scenario 1.

[ghost]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ezgambac]

@cston @333fred

[ezgambac]

@cston @333fred

[FaustVX]

null and false are 2 separate values.
You could write

if (a?.TryGetValue("h", out var _) ?? false)
    Console.WriteLine("Dictionary not null and found value found");
if (a?.TryGetValue("h", out var _) ?? true)
    Console.WriteLine("Dictionary null or found value found");

[CyrusNajmabadi]

Please make the behavior consistent so that != true and == false generate the same code,

We definitely cannot do this. This is a normal C# pattern and tehre is absolutely code out there that depends on the tri-state nullable-boolean semantics that the language has here (and has had since C# 2.0).

[ezgambac]

You should probably do an update of the docs to add an example of this, as I've only found a note here (https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types#lifted-operators), and it's been 20 years, your audience changes.

[chrisoverzero]

This doesn’t need to have to do with lifted operators. As Cyrus is implying, a truth table will show that these cannot be the same:

A	A != true
true	false
false	true
null	true

A	A == false
true	false
false	true
null	false

(This table will look different in SQL or VB.NET, for the record.)

TryGetValue should be false in this case by default, as there is no dictionary, which means no result, ergo false

Ergo null. The semantics of null-navigation mean that TryGetValue is never called if a is null. Even though your example uses discards, you should consider the effect that has on the definite assignment of the out parameter in such cases.

[iam3yal]

@ezgambac

who expects that != true and == false would mean different things

People who think that you're neither right nor wrong.

[DavidArno]

... who expects that != true and == false would mean different things, in any other C derived language afaik they are exchangeable and generate the same semantics .. it's been 20 years, your audience changes.

This is a valid point. To me, as someone who learned to program partially with ksh (where true is effectively 0 and false is any other value) and C, where false was 0 and potentially any other value could be used for true, I 100% would expect != true and == false to mean different things at times. I had it drummed into me in my 20s to never ever use == and != for boolean comparisons as the value of true wasn't defined in a reliable way. But times have changed and there is a whole generation raised on the sloppy "truthy" logic used in JavaScript and the like. Such folk assume null is false and seem to struggle with the idea that strongly typed languages don't work that way.

There arguably is a case for some good 101 documentation around this subject that really rams home that fact that there is no other value that is equivalent to false in C#. Not null, not 0, not anything unless one overloads equality to allow it. Tri-state booleans have three completely independent values: null and false are as dissimilar from each other as both are from true.

[CyrusNajmabadi]

your audience changes.

I'm happy to wait and see if that's the case and if we get enough feedback to indicate if there's an issue here. One person does not indicate that the audience has changed.

Furthermore, as I mentioned already, we literally could not change this. There is a ton of correct code dealing with nullable booleans written this way. It would break that code severely.

[theunrepentantgeek]

who expects that != true and == false would mean different things, in any other C derived language afaik they are exchangeable and generate the same semantics.

I don't think this is true.

In many C derived languages, there's no actual bool type - just a convention that 0 is false, and anything else is true.

Some of these literally use a preprocessor to do the "heavy lifting".

#define true -1
#define false 0

In those languages, the comparison == false is effectively == 0 but != true is effectively != -1 (actual constant may vary). Those have different semantics - which is why linting tools in those languages will often flag these comparisons as being doubtful.

It's also worth noting that practically the only places I ever write == false or == true is when dealing with nullable-bool values - for when the value is an actual bool, no comparison is necessary.

[iam3yal]

The normal interpretation would be that 1 and 2 should be interchangeable

By "normal interpretation" you really mean intuition, not what you might expect but there is only a single and objective interpretation here that's defined by the language.

[AartBluestoke]

The normal interpretation would be that 1 and 2 should be interchangeable,

anyone who has delt with sql has the intuition that you have to be careful with null - this is how sql would interpret these (in)equalities:
(NULL == false)==false
(NULL == true)==false
(NULL != false)==false
(NULL != true)==false