Hacker News Reader

Comment by eyegor | Hacker News Reader

Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the csproj files, including nullable reference types, even if you're using framework.

[0] https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...

View on HN

C# compiler doesn’t regard “x is object” or “x is null” as null checking statements, so you get warnings if you’re using nullable references.

Also, I don’t understand the scare over operator overloading. It’s not common and it works fine with nulls too as long as it’s implemented correctly. If it’s buggy, you’re screwed for other cases anyway, it isn’t much helpful to try to fix null checks only.

I find this advice overhyped because of these reasons.

Unity used to take advantage of overloading to implement null checking with "sentinel values" representing a non-existent reference in the Editor

I found this post explaining they considered moving away from the pattern, but I'm not sure if they followed through:

https://blogs.unity3d.com/2014/05/16/custom-operator-should-...

Yeah that means OP’s advice would actually break the code written for unity.

They didn't move away from the pattern and can't anymore as it would break almost every existing Unity project.

For performance reasons as well. An overloaded == operator turns a simple ceq into a function call, involving a new stack frame push and pop. If you do this on a hot path, switching to (is null) and (is object) can provide a significant speedup and will likely reduce gc pressure.

> The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types.

That's exactly the reason to use the opposite. In certain C# environments (like Unity game engine) the == is overloaded in a very meaningful way (when C# objects are used as representations of unmanaged objects, and they appear to "equal null" if the represented object is no longer available in the system), and using methods other than == to compare to null (such as casting to boolean) can introduce hard to detect bugs.

The new "something is not null" check in C#8 is "something is object/set"; for example: if (x is {})

Thanks. Just learned that object/tuple deconstruction works with is keyword as well (I mean makes sense). That makes argument checking so much less burden.

That also explains the switch in parameter checking from == null to is null for the default code analyzers/refactors/code hints.

a number of the C# lang developers prefer (x is object) for the latter, FWIW.

Yep, looking at the IL they are equivalent. And it definitely makes code prettier due to reduced parentheses. This is also true for generics.

Doing (x != null), !(x is null), or (x is object) all become:

    ldloc.s
    ldnull
    cgt.un
    stloc.s

why not add an operator so you can say (x !is null)?

Largely because (x is null) is a silly workaround to an uncommon and easily avoided problem (bad operator overloading).

No...

Reply on news.ycombinator.com