C# Pattern Matching

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 ]