4 ms·
It's also in some edge cases more correct, because you can't trust != to actually check for null. That edge case is when your (favorite) coworker did public st
by alkonaut 6y ago
It's also in some edge cases more correct, because you can't trust != to actually check for null.
That edge case is when your (favorite) coworker did
public static bool operator != (YourType x, YourType y)
=> DateTime.Now.DayOfWeek == DayOfWeek.Thursday;
Note to self when designing a language: no operator overloads on reference types.
- doodpants 6y agoOk, but if you have a coworker who's going to maliciously overload operators to behave differently than expected, then all bets are off and you have much bigger problems than how to check for null.
- alkonaut 6y agoI was half joking, obviously this is hopefully not done out of malice and hopefully whoever overloads the operator still handles the case != null logically equal to the expected way. There could be smaller differences than true correctness like performance too, not least since the != will be a virtual call that must be resolved, and also the overloaded implementation may or may not be as efficient as “is not null” is. This is a similar same issue as the “what’s wrong with using String instead of string” when it only breaks if someone adds their own type and calls it String, or aliases a type to String (with a capital S). This actually happens in actual code bases for various reasons not necessarily malicious.
- jayd16 6y agoIts not malicious or unheard of. Unity, a very popular game engine, overloads the == operator as well as the implicit boolean cast for their built in types. They do this because their types adhere to a specific lifecycle. When an object is dead, == null is true. I'm not a fan and its not super common but it happens.