Hacker News Reader

Comment by The_rationalist | Hacker News Reader

if (person is not null)

I really like it, it is more instantaneously readable than the usual != as it is more literate.

As mentioned in the link. Those are not equivalent because the != operator can be overloaded. I believe this is a less verbose version of

    if(Object.ReferenceEquals(person, null))

Person should have type Person, and null should have type Null. Then the compiler could make sure you didn't ever mix the two up! But I guess that ship sailed a while ago, and enough has been written on the matter.

I think I dislike `is not` though, mostly because `!=` still exists so now there's two of them. I already use the wrong null check in SQL[1], I don't want to use it in C# too.

[1] https://stackoverflow.com/questions/5658457/not-equal-operat...

> To compare if your value is not null, you use IS NOT NULL, while to compare with not null value, you use <> 'YOUR_VALUE'. I can't say if my value equals or not equals to NULL, but I can say if my value is NULL or NOT NULL. I can compare if my value is something other than NULL.

> think I dislike `is not` though, mostly because `!=` still exists so now there's two of them.

Note that "!= null" may behave differently than "is not null". != is an operator that can be overloaded, "is not" is not. Same counts for "is" and == when checking for null.

> Person should have type Person, and null should have type Null. Then the compiler could make sure you didn't ever mix the two up! But I guess that ship sailed a while ago, and enough has been written on the matter.

You can somewhat get that in C# nowadays: https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...

It's nice, but C# already had `person is {}` which whilst it requires a bit more familiarity with C# extends to more uses like `person is { name: "Rationalist" }`.

You can also do "person is object", which seems to make sense to me.

It's also in some edge cases more correct, because you can't trust != to actually check for null. That edge case is when your (favorite) coworker did

public static bool operator != (YourType x, YourType y) => DateTime.Now.DayOfWeek == DayOfWeek.Thursday;

Note to self when designing a language: no operator overloads on reference types.

Ok, but if you have a coworker who's going to maliciously overload operators to behave differently than expected, then all bets are off and you have much bigger problems than how to check for null.

I was half joking, obviously this is hopefully not done out of malice and hopefully whoever overloads the operator still handles the case != null logically equal to the expected way. There could be smaller differences than true correctness like performance too, not least since the != will be a virtual call that must be resolved, and also the overloaded implementation may or may not be as efficient as “is not null” is.

This is a similar same issue as the “what’s wrong with using String instead of string” when it only breaks if someone adds their own type and calls it String, or aliases a type to String (with a capital S). This actually happens in actual code bases for various reasons not necessarily malicious.

Its not malicious or unheard of. Unity, a very popular game engine, overloads the == operator as well as the implicit boolean cast for their built in types. They do this because their types adhere to a specific lifecycle. When an object is dead, == null is true.

I'm not a fan and its not super common but it happens.

Reply on news.ycombinator.com