Add pythonic if statement to C#

[talley]

It will be nice if C# can add this if feature of Python.
Example in python

countries =['USA','Germany','France','Togo'];
i can just write this if statement in python
if(countries):  #the compiler will know that countries is a list and it will check whether countries is null or not 
#{
  # process your code here
#}

schools=100
if(schools): #the compiler will know that schools is int type and it will check whether schools is null or not 
#{
  # process your code here
#}

In C# i will have to do something like:

if(schools>0)
{

}
or
if(countries.Any())
{

}

It will be nice if we can have the same feature in C#

Talley Ouro
Software Engineer
Raleigh,NC,USA

[HaloFour]

The explicit nature of bool and conditionals in C# stems from the fact that such loosey behavior is a known vector for bugs. See C++ and JavaScript.

[Joe4evr]

Also, could you in the future perhaps use proper markdown? Your post is nearly unreadable. Thanks.

[talley]

@HaloFour i use this technique in Python every day and Python compiler is not complaining or throwing bugs .

[HaloFour]

@talley

i use this technique in Python every day and Python compiler is not complaining or throwing bugs .

"Not complaining" is the problem. "Loose" conditions allow for the developer to accidentally code an unintended behavior which the compiler will happily allow. The end result is a logic bug that can be difficult to troubleshoot because the code is perfectly legal.

For example, in C++ the result of an assignment is the assigned value. C++ also allows conditions directly on integer variables where true is any non-zero value. So the following is legal:

int foo( int value )
{
    if (value = 123)
    {
        return 0;
    }
    return 1;
}

This function is perfectly legal but will always return 0 because what happens is that the value 123 is being assigned to the variable value and then the condition checks that value is non-zero, which will always be the case.

In Python there does seem to be the difference that an assignment expression is not permitted within an arbitrary expression, which does mitigate the C++ flavor of this problem. But for better or for worse the C# language inherited the behavior of the C++ language which does allow said assignments. So the C# language made the decision to not allow arbitrary expressions to evaluate to bool based on their non-zero- or non-null-ness. It's much too late to reconsider those behaviors now.

[bondsbw]

And don't forget other gotchas even with Python's truthiness:

>>> 't' if 0 else 'f'
'f'
>>> 't' if 1 else 'f'
't'
>>> 't' if '0' else 'f'
't'
>>> 't' if '1' else 'f'
't'

[scalablecory]

@talley C# prescribes to the notion of catching as many bugs as possible at compile time, and a major focus for C# 8 is to further strengthen that ability. This change would be counter to those goals.

Not saying it doesn't work for Python. It just doesn't work for C#.

[talley]

Thank you @HaloFour and @scalablecory for the clarification but C# team can make this optional too.So it is up to the developer to choose his flavor.

[orthoxerox]

@talley and the flavor you might want is called IronPython.

[CyrusNajmabadi]

So it is up to the developer to choose his flavor.

We don't like flavors (i.e. dialects) of C#. It leads to community and ecosystem bifurcation.

[HaloFour]

@talley

So it is up to the developer to choose his flavor.

If you are referring to a command line option to change the semantics of the compiler the team has made it clear on several occasions that they have no interest in doing so.

If you are referring to the compiler simply allowing such comparisons so that developers can choose which they want to use, all that does is expose the vector for bugs. Developers who believe that they are choosing an explicit comparison would accidentally get an assignment through a simple typo. That is the very reason why the C# team explicitly made the decision to disallow such comparisons and to break with C++ semantics with the original release of the language. It's not worth it just to save a couple of characters.

[MgSam]

We don't like flavors (i.e. dialects) of C#. It leads to community and ecosystem bifurcation.

If you are referring to a command line option to change the semantics of the compiler the team has made it clear on several occasions that they have no interest in doing so.

Except if its a flavor of C# the team does like, like with the upcoming nullability checking and checked/unchecked math. 🤷‍♂️

I think it's more accurate to say that putting options behind command line switches requires an extremely high bar of usefulness, which few would say this proposed feature meets.

[CyrusNajmabadi]

and checked/unchecked math.

We don't like that we did this.

Except if its a flavor of C# the team does like, like with the upcoming nullability checking

Yes. As you mentioned, we will do this if there is enormously high benefit. Hence "we don't like" it. We will do it if the value is enormous though. Being able to help eliminate null is at that level though.

[dsaf]

Surely this will be possible with implicit conversion extension operators?

[talley]

@CyrusNajmabadi "So it is up to the developer to choose his flavor." = well add it to the language and it is up to the developer to choose it on his own risk.For example i deal work with an C# application which handle 100000 requests per second.I use asyn/await to deal with this but my co-worker prefer to avoid it to similar application.This what i meant by that. Is it doable or not?This is the answer i need.

[HaloFour]

@talley

It's not possible to dig a pit into the language without everyone potentially falling into it. The team made an explicit decision to not repeat the mistakes of C++ based on real data regarding the problems caused by that language feature 16 years ago. I think that you'd have to demonstrate evidence that shows that relaxing the language won't reintroduce the problem, and mitigating the issue in the same manner as python is not possible as it is a breaking change.

[talley]

@HaloFour 👍

[Saleca]

I like the idea of

if(object) compiling as if(object is not null)

there`s not much room for error in my opinion, but I dont work in teams, so I can be short-sighted

in the other hand there are multiple ways to do the same thing, some are similar and lead to the same result and some are identical, i dont see why people dislike so much that idea in here.

unity implemented that and is really useful, again in my opinion.

[CyrusNajmabadi]

This is highly unlikely to ever happen. It's a core part of c# through and through that we do not define truthyness for things that are not booleans. If types want to support truthyness, they can do so with operator true/false.

We are practically never going ot make null truthy/falsy.

[bondsbw]

I’d rather get rid of null, not encourage its use.