Proposal: Definite assignment involving == and != when compared to a constant boolean value

[NightElfik]

Definite assignment should take into account boolean expressions involving == and != when compared to a constant boolean value. This is continutation of thread from Roslyn.

This code is currently not valid and results in "Use of unassigned local variable" error.

string example(object obj) {
    if ((obj is string str) == false) {
        return;
    }
    return str;
}

However, logically identical code like this works:

string example(object obj) {
    if (!(obj is string str)) {
        return;
    }
    return str;
}

We like to use == flase instead of ! in our code base for added readability. The ! is easily overlooked when skimming through the code.

[DavidArno]

We like to use == false instead of ! in our code base for added readability. The ! is easily overlooked when skimming through the code.

I disagree. When I encounter expr == false, I mentally have to stop, translate it to !expr and carry on. == false makes the code less readable to me. Readability is subjective in this regard: it depends on what you are used to reading.

However, some folk, like you, prefer == false, so I see no reason why the compiler shouldn't better support such folk.

[jveselka]

The place I arrived to is that ! is better for short conditions and == false for long ones (especialy when chaining methods)

if (myCollection.Where(x => x != null).SelectMany(x => x.SomeProperty).Any() == false)

So I aggree as well that the compiler should support both uses.

[jnm2]

Also remember it's possible to be comparing to a const bool.

[amis92]

Just so you know of possibly related/migth-solve-this-use-case issues:

• Feature Request - new operator keyword: is not #27 (is not keyword)
• Proposal/Discussion: Negation of if/while Condition #568 (Negation of if/while)

[miloush]

I don't think this is a discussion of style. I would argue this is an actual compiler bug where
if (o is string s) and if ((o is string s) == true) behave differently and they shouldn't.

[jnm2]

I don't think this is a discussion of style. I would argue this is an actual compiler bug where if (o is string s) and if ((o is string s) == true) behave differently and they shouldn't.

Absolutely right. Perhaps this should be moved to dotnet/roslyn.

[CyrusNajmabadi]

This is the correct locatoin. The compiler is functioning as per the language spec. We'd need the language/spec to be updated in order to make any changes here in the compiler.

[HaloFour]

I agree that the current syntax is a little bit limiting but there is certainly a "can of worms" issue to contend with here and I think that the spec does need to draw a hard line in the sand somewhere. It's not a far leap to full-blown flow analysis, the expectation that the following would work:

bool result = o is string s;
if (result) Console.WriteLine(s);

And a myriad of other complex cases.

Of course with flow analysis being potentially in the pipeline for C# non-nullable references maybe there could be some shared opportunities. And as this only expands on when a variable is definitely assigned it can be explored without possibly introducing breaking changes.

[sharwell]

I would prefer to expand this slightly.

The Boolean value for "definitely assigned when true" (DAWT) or "definitely assigned when false" (DAWF) may be evaluated as part of an expression, where the replacement of the Boolean value with either true or false yields a Boolean constant. The result of the expression is determined according to the following table:

Expression value when true	Expression value when false	Result for DAWT	Result for DAWF
true	false	DAWT	DAWF
false	true	DAWF	DAWT
true	true	DAWF	DAWF
false	false	DAWT	DAWT

[gafter]

@sharwell I have no idea what that means.

[SylwesterZarebski]

Is there anything simple programmer can do to push this issue further?

[gafter]

This is a request for a proposal, not a proposal, as it contains no details for how the language specification should be modified to accomplish the purpose. A first step to making this happen would be to get someone from the language design team interested enough to champion it. A next step for someone wanting this to happen would be to propose a set of changes to the language specification, and then prototype those changes in the compiler. These are all necessary steps.

[skendrot]

We're nearly three years after the initial issue for this. Is there any movement here?

[gafter]

@skendrot As far as I know nobody has yet proposed a specific language change to accomplish this. If you feel this issue is important that would be a good first step for you to take.

[OlsonDev]

How does one even do this? The current spec is for C# 6... so, if we wanted this in C# 9.1 or 10 (or whatever), how could we possibly know all the specific language changes necessary if there's a whole 3 language versions which haven't been spec'd?

[CyrusNajmabadi]

How does one even do this?

In general, you can start by giving a general intuition on how hte existing rules would change. This can be formalized into a precise set of new rules.

how could we possibly know all the specific language changes necessary

In general, getting 80% of the way there is enough. The team can take the rest from that point.

[RikkiGibson]

Ideally you do it by writing a proposal which describes what changes should be made to this section of the spec: https://github.com/dotnet/csharplang/blob/master/spec/variables.md#precise-rules-for-determining-definite-assignment

I've been working on this, and I'll make sure to follow up here when I have a proposal that is ready for review.

[RikkiGibson]

Spec proposal has been submitted here: #4240

[sumtec]

Glad to know that this is finally fixed!
I actually mentioned this issue earlier but rejected: dotnet/roslyn#17828
A bit sad at that time. 😄