C# Pattern Matching

Re:C# Pattern Matching by eyegor on Tuesday February 04, 2020 @07:37PM (#22242838)

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...

[ Parent | on HN ]

Re:C# Pattern Matching by sedatk on Wednesday February 05, 2020 @01:03AM (#22244391)

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.

[ Parent | on HN ]

Re:C# Pattern Matching by BoorishBears on Wednesday February 05, 2020 @01:08AM (#22244408)

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-...

[ Parent | on HN ]

Re:C# Pattern Matching by marijnz on Wednesday February 05, 2020 @01:47AM (#22244576)

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

[ Parent | on HN ]

Re:C# Pattern Matching by sedatk on Wednesday February 05, 2020 @01:40AM (#22244553)

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

[ Parent | on HN ]

Re:C# Pattern Matching by eyegor on Wednesday February 05, 2020 @07:37AM (#22246219)

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.

[ Parent | on HN ]

Re:C# Pattern Matching by golergka on Wednesday February 05, 2020 @02:36AM (#22244769)

> 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.

[ Parent | on HN ]

Re:C# Pattern Matching by pbz on Tuesday February 04, 2020 @10:11PM (#22243669)

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

[ Parent | on HN ]

Re:C# Pattern Matching by oaiey on Wednesday February 05, 2020 @03:32AM (#22245003)

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.

[ Parent | on HN ]

Re:C# Pattern Matching by Serow225 on Tuesday February 04, 2020 @09:41PM (#22243525)

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

[ Parent | on HN ]

Re:C# Pattern Matching by eyegor on Tuesday February 04, 2020 @10:45PM (#22243826)

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

[ Parent | on HN ]

Re:C# Pattern Matching by earenndil on Wednesday February 05, 2020 @03:16AM (#22244920)

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

[ Parent | on HN ]

Re:C# Pattern Matching by gregoryl on Wednesday February 05, 2020 @05:17AM (#22245517)

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

[ Parent | on HN ]

Re:C# Pattern Matching by sabana on Wednesday February 05, 2020 @04:57AM (#22245439)

No...

[ Parent | on HN ]