3 ms·

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 und

by sedatk 7y ago

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.

BoorishBears 7y ago
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-we-keep-it/?_ga=2.39545259.946914061.1580882722-813850683.1580882722 https://blogs.unity3d.com/2014/05/16/custom-operator-should-...
- sedatk 7y ago
  Yeah that means OP’s advice would actually break the code written for unity.
- marijnz 7y ago
  They didn't move away from the pattern and can't anymore as it would break almost every existing Unity project.
eyegor 7y ago
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.