Nullable reference tracking and bitwise operators

[Tinister]

I have this code fragment here which works great:

if (validateEmail(config.PrimaryEmail, nameof(config.PrimaryEmail)) &&
    validateEmail(config.SecondaryEmail, nameof(config.SecondaryEmail)) &&
    validatePath(config.ClientSecretPath, nameof(config.ClientSecretPath), mustExist: true, out FileInfo? clientSecretFile) &&
    validatePath(config.PrimaryDiffPath, nameof(config.PrimaryDiffPath), mustExist: false, out FileInfo? primaryDiffFile) &&
    validatePath(config.SecondaryDiffPath, nameof(config.SecondaryDiffPath), mustExist: false, out FileInfo? secondaryDiffFile))
    return new Settings(
        config.PrimaryEmail.Trim(),
        config.SecondaryEmail.Trim(),
        clientSecretFile,
        primaryDiffFile,
        secondaryDiffFile);

static bool validateEmail([NotNullWhen(true)] string? email, string settingName) { ... }

static bool validatePath([NotNullWhen(true)] string? path, string settingName, bool mustExist, [NotNullWhen(true)] out FileInfo? file) { ... }

However, if I change the logical-and operators to bitwise-and operators (&& to &), then I get warnings for the expressions in the Settings constructor ("X may be null here"). Which doesn't seem correct; when do logical and bitwise operators compute different results?

My reasoning for wanting to do bitwise here is that these validate methods log why the setting is invalid. With bitwise-and it'll check all the settings and if there's two-or-more problems they'll all be logged. With logical-and it'll only log the first invalid setting.

[TahirAhmadov]

This is to be expected. The nullability analysis relies on logical operators to deduce whether any given variable can be null. Bitwise operators are not logical, and are therefore invalid for nullability analysis.

[TahirAhmadov]

To achieve your desired behavior, you should split it into multiple if statements.

[CyrusNajmabadi]

& is a logical operator when applied to bools. The only difference is that it is not short-circuiting, while && is.

In this case, i imagine the reason here is that we just simply didn't think this was a priority, and we would need a substantive amount of people indicating this pattern was common to warrant doing something here. That said, perhaps @RikkiGibson can weigh in on his views if this would be worthwhile to add support for.

[RikkiGibson]

https://stackoverflow.com/questions/61076184/why-do-i-get-dereference-of-a-possibly-null-reference-warning-when-using-non-sho/68824025#68824025

There's a perf tradeoff to consider before doing anything here. Basically, to do an accurate analysis we would need to double-visit the right operand.

I was concerned that this would be problematic in the scenario given in the original post here, but since most binary operators including & are actually left-associative, i.e. A & B & C means (A & B) & C, it might be uncommon for the double-visit to be problematic even with long chains of logical operators, etc. If it were right-associative I think it would be a bigger problem.