3 ms·
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 c
by eyegor 7y ago
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-references https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...
- Serow225 7y agoa number of the C# lang developers prefer (x is object) for the latter, FWIW.
- eyegor 7y agoYep, 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
- earenndil 7y agowhy not add an operator so you can say (x !is null)?
- gregoryl 7y agoLargely because (x is null) is a silly workaround to an uncommon and easily avoided problem (bad operator overloading).
- pbz 7y agoThe new "something is not null" check in C#8 is "something is object/set"; for example: if (x is {})
- oaiey 7y agoThanks. 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.
- sedatk 7y agoC# 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 agoUnity 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-...
- eyegor 7y agoFor 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.
- golergka 7y ago> 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.
- sabana 7y agoNo...