Discussion: null evaluation operator to boolean

[lachbaer]

Since the beginning of C# I dislike the extensive use of obj == null comparisons.

On one hand C# is quite verbose and needs a handful of charaters to express a simple thing, on the other hand there is done quite effort to shorten code, like e.g. expression bodies, null-coalescing operators, etc.

From C I much like the fact that null evaluates to boolean false and !null to true.

I'm not sure about a possible syntax. Because C# is type safe and the existing obj == null has its reason, an operator must be something conspicuous to make clear that the following reference is evaluated to true or false. It could be e.g. an unary ? operator (like e.g. unary +, - and ~)

if (obj != null) DoIfNotNull();
// goes to 
if ( ?obj ) DoIfNotNull();

if (obj == null) obj = new Object();
// goes to
if ( ! ?obj) obj = new Object();

Together with #157, where putting the not operator ! in front of for and while clauses to negate the expression it could be something like

if ?( obj ) DoIfNotNull();
if !?( obj) obj = new Object();

[HaloFour]

I believe that the decision that C# could only evaluate Boolean conditions (and limits what can be considered such) was very intentional, specifically to avoid the assortment of logic errors caused by minor typos in the C language. For example, your change would make the following legal, and very wrong:

if (obj = null) { // oops!
    DoIfNotNull();
}

[svick]

@HaloFour I agree that the code you showed should not be allowed, but this proposal does not suggest to allow it. Instead, you would have to include the ? operator:

if (?(obj = null))

Or:

if ?(obj = null)

I think this means the error is not easy to make this way, which is why I personally don't oppose this proposal.

(I'm curious why so many people downvoted this. Did they misunderstood the proposal too? Or do they just not like the syntax or the proposal in general?)

[jnm2]

Didn't downvote but I'm far from convinced that adding syntax makes null checking any more readable than == null already is.

[lachbaer]

@HaloFour It is good that it was made intentionally, actually I think that it is a side product of type safety.

I do not intend to allow obj = null, at least not if explicitly stated to be allowed. It should be something like

String s = null;
if ( s?.Length > 0) { ... }

where first s?.Length is converted to nullable type int? and then compared to (int?) 0, what produces false in case of s being null. But here it is just for obj == null, like in C and type safe.

@jnm2 I want to avoid writing things like

while ( ( item  = collection?.Next() ) != null ) { ... }

when they can be written

while ( ?! item = collection?.Next() ) { ... }

I think it would be enough to make this available to all if-condition like contexts, where the condition evaluates to true like in C where it is not null, 0, 0.0 or false, respectively default(T).

So it actually comes down to an operator that implicitly cast every type to (bool). And that operator should be brief.

[lachbaer]

Such an operator could be ?!, because ? is already used in many nullable scenarios and ! just stating not, so ?! => null not [not null]. It should have the same precedence as assignment operators, evaluated from right to left.
And together with #157 it could be written before the condition braces

while ?!( item = collection?.Next() ) { ... }

[MillKaDe]

As far as I understand the proposal of @lachbaer, he did not suggest that C# adopts the automatic conversion of everything to bool.

Instead he suggests a unary prefix operator '?' for all reference type, that checks if the reference is not null, e.g. something like this:

static public bool operator<T> ? (this T reference) where T : class
{
  return reference != null;
}

Yes, thats not valid C#, but I hope everybody understands what it means anyway ...

Instead of the automatic conversion to bool from C/C++, C# would require explicit usage of the suggested new 'notnull' operator to 'convert' the reference to bool.

For example ..

if (?obj) DoSomethingWith (obj);

.. would be a shorter version of ..

if (obj != null) DoSomethingWith (obj);

That shorter version is at least as readable as the null-conditional operator '?.' which was introduced in C# 6:

obj?.DoSomething ();

Because bool already has an unary prefix operator ! to negate a bool, checking for null (instead of not null) would be possible by combiniation of '!' and '?', e.g. writing ..

if (!(?obj)) obj = new FooBar ();

.. or even better (if precedence and associativity of the new operator are defined apropriately) without additional parenthesis ..

if (!?obj) obj = new FooBar ();

.. as a shorter version of ..

if (obj == null) obj = new FooBar ();

The motivation is of course to have a syntax for reference checking, that is almost as short as in C/C++, but without inheriting all the problems and bugs of automatic conversion to bool.

In my humble opinion, the suggested notnull operator would be really nice to have in a future version of C#.

Update:
I would prefer if (?obj) .. over if ?(obj) ...

[MillKaDe]

Hmm, looks like there are several questions:

1. do we want/need an operator (e.g. '?') to check for (x != null) ?
2. whats the best syntax ?
3. do we want/need another operator (e.g. '!?') to check for (x == null) ?
4. can we use just use the first operator (?) combined with bool negation (!) instead of a second operator ?
5. shall the operator be defined only for references (x != null) or extended to value types (x != 0) or (x != default(X)) ?

[stepanbenes]

If you like to write so many question marks and exclamation marks I just want to let you know that there is this beautiful language Ook?!.

[lachbaer]

Meanwhile I would go with =! default(T)

static public bool operator<T> ? (this T value)
    => value != default(T);

because there are ongoing discussions (sorry, don't have the threads by hand) about defining own default's for value types, defaults for Tuples and so on.

if (obj == null) obj = new FooBar ();
// vs.
if (!?obj) obj = new FooBar ();

I think !?obj is a bit cryptic and confusing in this way and shouldn't be used (maybe issue a warning), but it would be legal. It would be better to write that example with

obj = obj ?? new FooBar();
// or with roslyn/dotnet#205
obj ??= new FooBar();

[jnm2]

@lachbaer

@jnm2 I want to avoid writing things like

while ( ( item  = collection?.Next() ) != null ) { ... }

when they can be written

while ( ?! item = collection?.Next() ) { ... }

I find the first example much more readable and natural, so there is definitely subjectivity to this.

Also, !item = x is currently the same as saying (!item) = x which is illegal (CS0131), so I would expect that you'd need the parentheses:

while ( ?!(item = collection?.Next()) ) { ... }

If you remove the parentheses, I'd expect operator precedence to be the equivalent of (?!item) = collection?.Next() which should fail with CS0131.

Since the parentheses are necessary, the question is whether ?(expression) is more readable than (expression) == null. I'm still far from convinced.

[lachbaer]

I don't feel as ? is the right character for this, because by now the ? operator says "if it is set, then use it", like with ?. and ??.

But here the negation is more of a subject: if (obj != null) ThenUseIt();

Would !! stand out better?

if ( !! obj ) { UseObject(); }

! is a unary boolean already and ! ! would override itself, so to say being neutral. I doubt anybody wrote this ( or bool b = !!!!!!!!!! true; 😉 ) in actual code, so two !! would take precedence during parsing.

[HaloFour]

@svick

You're right, I jumped the gun on responding there.

That said, this proposal seems to be about adding a "Truthiness" operator to C#. What real benefit does that provide? Is actually explicitly specifying the comparison being performed such a burden? I don't think so. Even assuming C# doesn't totally botch up "Truthiness" to the extent that JavaScript did I don't see any need to have some manner through which arbitrary values are evaluated to a Boolean result. It hides too many details, such as the specific type and what that comparison really means. You save typing a few characters at the expense of understanding what that code will do later. Not worth it, in my opinion.

What would the following mean? Null check? Zero check? Both?

int? x = 0;
if (?x) { ... }

[lachbaer]

@HaloFour
As stated above I don't think that ? is the right operator for this. I'll go with !! for now.

What would the following mean? Null check? Zero check? Both?

int? x = 0;
if (!!x) { ... }

it would mean "if x is set to something other than it's default value". For ref types that would be x!=null, for nullable type it would also be null, so the above statement would be true.
But you are right that one could understand it as if (x!=0). So maybe in the case of standard value types it should just be both, giving the meaning "if x has something valuable to work with".

int? x = 0;
if ( x.HasValue && x != 0 ) { ... }  // or just `x != 0`

[HaloFour]

@lachbaer

As stated above I don't think that ? is the right operator for this. I'll go with !! for now.

Fairly sure that will result in ambiguities. ! is already the unary negation operator and the compiler allows you to apply it multiple times if you see fit. bool b = false; if(!!b) { } is already perfectly legal.

Either way, the syntax of the operator is less important than what it does. It hides how the comparisons are made, and in the case of nullable structs there aren't "right answers".

[lachbaer]

@HaloFour

and in the case of nullable structs there aren't "right answers"

For me =! default(T) is quite definite, and if it is extended for nullable primitive types to =! 0 (or alike) I think that's also clear. No, I don't see any ambiguities.

PS: The character is currently not of interest, let it be § if you like 😉 I just think that ?is definitely not appropriate

[dmitriyse]

Please describe some one who already dived into this problem deeply, what is wrong with this approach:

1. Ref => implicit cast to Boolean now allowed (null === false) (probably with restriction to built-in flow constructions if, while, for, ?:, etc.).
2. || and && operators now can work with reference type operands and (null === false)

?

[MillKaDe]

to @lachbaer

I agree that t.GetValueOrDefault is preferable over ?t?.Value in a context where it is known that t is of type Nullable<T>.
But in some non-nullable context, ?x?.y (field y in class x) might still make sense.

[lachbaer]

@MillKaDe Yes ?x?.y of course is valid for explicit field access and really makes sense to me. I even directly understand its represenation, even if it looks a bit awkward on first sight. Just in case of Nullable's GetValueOrDefault could be better, because it directly states that I am interested in the value of it being null or unequal to 0.

@dmitriyse Sorry, I don't understand you. What does === mean? Is it a new feature I don't know about?

[dmitriyse]

Mathematical Identity it's usually defined by symbol ≡. Just read null ≡ false or "interpreted as false".
I propose not to use any new operator.
Just limited implicit cast from null to false. In "if", "while", "for", "?:" and in || and && operators.

if (someRefVar) // allowed
{
}
if (!someRefVar) //not allowed use classic if (someRefVar == null)
{
}

if (someRefA && someRefB) // allowed
{
}

if (someRefA & someRefB) // not allowed
{

}

Advantage - no any new operators, intuitive.
Disadvantages - limited use cases.

[MillKaDe]

to @dmitriyse

I fear I don't understand your question(s).

1. Implicit cast to bool
   There is a loooooong list of possible errors in C/C++ because of implicit cast to bool, e.g.

   // possible typing error, but legal in C
   if (a = b) .. // assigment of b to a, then converted to bool, meaning (b != 0)
   // versus most likely intention
   if (a == b) .. //

   We would like to avoid these kind of bugs. This suggestion tries to block those problems by requiring explicit use of this new check operator.

2. Logical operators ('&&', '||')
   The result of the new '?' operator is bool. So several check can be combined, e.g.

   if (?x && !?y) ..
   while (?x || ?y) ..

3. Operator '==='
   C# has no triple equal operator (yet).
   As far as I know, in JavaScript, '===' is a stricter equal then '==', e.g.

   "2" == 2 // is true, cause string "2" has the same 'value' (or maybe lets better call it meaning) as int 2
   "2" === 2 // is false, cause their types are different - a string is not an int
   

   but I might be wrong because I don't know much about JavaScript ..

[MillKaDe]

to @dmitriyse

Ah, OK - now I understand a bit more ..
But I am pretty sure that the language design team will not allow implicit cast to bool - neither in general nor limited to special places. Some explicitness (for example an operator) is needed to block the errors from C/C++ sneaking in ..

[MillKaDe]

Oh, and there is an aspect we have not discussed yet - should it be possible to overload that new check operator ?
Always ? Never ? Just for some types ?
I think it should not be possible to overload it, especially not for reference types or primitive value types (e.g. the int types, bool, float, double, decimal)

But what about user defined value types, e.g. struct Point { int x; int y; } ?
Or maybe the new check operator will be limited to refs and primitive value types, because it is considered to be too 'expensive' on non-primitive value types, e.g.

Point p; // a user defined struct / value type
if (?p) .. // what does that mean ? Should that be legal ?

Does it mean (?p.x || ?p.y) (= p.x != 0 || p.y != 0) ?

[dmitriyse]

@MillKaDe Thanks for you description. I forgot about "if (a=b)" like problems.

[lachbaer]

@MillKaDe @dmitriyse
Exactly, we do not want implicit casting, for many, many good reasons! It is one of the main sources of errors in C/C++ and other languages!

This proposal is about a "is-non-default" operator. Maybe one day there will be an
T operator default(T rhs) { }; that returns a new instance of any type (value/ref/Nullable).
In that case ?obj will return true if it is either null (because ? somehow stands for a not-null-checking)
or !obj.Equals(default(T)).

The correct equivalent of ?x so would be:

bool isNotNullOrDefaultQuestionmarkOperator<T>(T x) where T : class
    => ! ( ( x == null ) || ( x.Equals(default(T)) ) );

bool isNotNullOrDefaultQuestionmarkOperator<T>(T x) where T : struct
    =>  x.Equals(default(T));

bool isNotNullOrDefaultQuestionmarkOperator<T>(T? x) where T : struct
    =>  x.HasValue;

[lachbaer]

@MillKaDe

should it be possible to overload that new check operator ?

No, not in my understanding (see directly above). The 'overloading' would be done with a default-operator. This way ? will also work with the new record types.

[MillKaDe]

@lachbaer

About non-zero defaults:
The default value default (T) is always a bunch of zero bits. The type T determines the type and the size / number of bits of that bunch of zero bits.

Why ? see this answer by Jon Skeet on stackoverflow.

A class / reference type C may have a parameterless default constructor, which can set the fields of the constructed object to any desired values. But the default value of the reference to that new object (the address/pointer in C/C++) itself is null (= 0).

In C# a struct / value type S is not allowed to have a default constructor (which has no parameters). The closest thing to a non-zero default value is :

struct S {
  public readonly MyDefaultValueForS = new S (42);
}

but default (S) must be all zero.

When an array of S S[..] is allocated, the runtime sets all bits in that array to zero.
There are no calls of an default constructor of S for all the array elements.
Instead the NET runtime does something like memset (s, 0, sizeof (array)) (from C/C++ runtime lib) on the whole array.

No matter how complex a type definition is, it always forms a tree-like graph. All fields of any type are always either

• one of the predefined primitive value types (ints, bool, float/double/decimal),
• a reference (pointer) to another object / class
• an embedded struct

but any embedded struct follows these rules too, so sooner or later you will reach the leafes of the tree/graph and all leafs are either

• one of the predefined primitive value types (ints, bool, float/double/decimal) - all with default value zero
• a reference (pointer) to another object / class - with default value zero.

Introducing some way to define non-zero default values - no matter how - would be a breaking change, which the language design team tries to avoid by all means.
So I think there will never be a T operator default(T rhs) { ... }.

About overloading the new check operator:
Because the default value always is (and always will be) zero bits, the check operator for type T can always (for all types) compare to default (T).

The new check operator should be predefined and not overloadable for:

• references
• all integer types: [u]int, [u]long, [u]short, [s]byte and [U]IntPtr (aka native int)
• all enums, which are just ints with named values
• all non-integer number types: float, double, decimal
• bool

The check operator would be most useful for references, and also useful for ints.
It is not so useful for enums and non-integers.
And it is not needed at all for bools, cause it would just return the bool itself - but maybe it make sense to define it anyway for symmetry reasons and fewer problems when used in generic types ?

I don't think it makes sense to allow the user to define the check operator for user defined structs, because its implementation would always have to be the very same:

public static bool operator ? (S s) {
  foreach (var field in struct.fields) {
    if (?field.value) return true; // found one field with non-default value
  }
  return false; // all fields have default value
}

However, this implementation could be a generated by the compiler.

As far as I know, the method System.Object.Equals (System.Object x) does some automatic memberwise comparison of all fields, when two structs of same type are compared with that Equals method.
So a compiler generated standard implemention for operator '?' would be technically possible.
But I don't think that it is desperately needed.
But - again - it might make sense for symmetry and simpler use in generic types.

[lachbaer]

In Roslyn I (also) found

Debug.Assert(!isExtensionMethod || (receiverOpt != null));

Because ! is easily overseen (see #157), it should be either

Debug.Assert((isExtensionMethod == false) || (receiverOpt != null));

throughout the codebase.

Or we have another argument in favor of this proposal, because ? is not worse than !.

Debug.Assert(!isExtensionMethod || ?receiverOpt);

I like brevity - as long as it is understandable. So I still like the ? operator! 😍

[lachbaer]

Meanwhile I do not think that there should be an implicit operator like this. For value types this could be achieved in a safe way by delacring custom 'struct' types, when really needed.

    public struct BoolInt
    {
        public int Value { get; set; }
        public BoolInt(int value) => Value = value;
        public static implicit operator bool(BoolInt rhs) => rhs.Value != 0;
        public static implicit operator BoolInt(bool rhs) => rhs ? -1 : 0;
        public static implicit operator int(BoolInt rhs) => rhs.Value;
        public static implicit operator BoolInt(int rhs) => new BoolInt(rhs);
        /* further operators */
    }
BoolInt v1 = 10;
while (v1) --v1;

I'd rather see an bool operator ? that gets called in the following scenarios

if (?secondItem) {
    var item = fistItem ?? secondItem;
    item?.Execute();
}

In all 3 scenarios the ?s check for 'null' in the first step and when the custom bool operator ? exists on the type (value or reference) calls it. Value types can't be 'null', instead the missing of the custom operator on the type makes all 3 statements produce a compile time error.
This would have no impact on current code, even the IL is the same.

[lachbaer]

See also #545 for specific proposal of ?obj. Neither has support.

[kennetherland]

Why not just have the editor change if (obj) to if (obj != null) as autocorrect or AI assisted feature.
Reverse, if (!obj) autocorrect to if (obj == null)

[jnm2]

This has been discussed in other threads at length. See #843 for instance.