However, `null` value is not a good way to use a default value instead of an object. When it comes to polymorphism, we would like to avoid null checks from being all around. The same goes not only for `->`, but also return / argument type-hintings.
Why do we even need to know that object can be null? Null is just a special case (there may be other special cases). Does my customer code need to know about all special cases? Apparently not. But still, we create another operator to handle this case. It is ok when it comes to third-party libraries we don't have control over and sometimes it could return null. Yet this approach doesn't solve the primary problem. Polymorphism. You can argue that `null` can be used to indicate that something was not found. But this is not the case for returning null. Here an exception should be thrown. When I would like to return some default value of an object, it can't just be null (because it will pile up the code with ? signs). I need to create a separate NullObject, which implements a particular interface used at runtime, and return it's instance. If an interface declares a returning object, then I have to write even more boilerplate code for those objects. It is all for such thing as the default "null" value for an object. IMHO, simple things should be done in a simple way. What I currently see is that to do a simple thing, I need to create `N` `null`-classes, whose methods will eventually return `""` or `0` or `0.0` or `false` or `[]` - generally speaking `null`. On Tue, Nov 3, 2020 at 9:56 PM Claude Pache <claude.pa...@gmail.com> wrote: > > > > Le 3 nov. 2020 à 17:38, Eugene Sidelnyk <zsidel...@gmail.com> a écrit : > > > > Hello, internals! > > I am wondering why don't we use ordinary `->` operator with safe null > > handling? Programmers will be more prone to return null values. And thus, > > in most of cases `?->` will replace `->`. > > Why do we need another operator, if we can implement null safe in current > > operator without BC breaks? > > Hi, > > In a parallel world where people never commit bugs, yes, this is > reasonable semantics. > > However, it happens more than once that a null value occurs by accident > where an object is expected by the programmer. In this case, I very much > prefer to have a Warning or an Error, typically handled by an error handler > which sends a bug report to the developer, then triggers an emergency stop. > That makes it much easier to locate and fix bugs. > > Of course, this debuggability facility have to be balanced with the > inconvenience to having to write more code in cases where a null value is > expected. Having to write “?->” instead of “->” in those cases is a minimal > inconvenience. Here, I mean “minimal” in a very literal way: exactly one > character of difference. > > Also, there is the following benefit: When I write “->”, I am stating that > the LHS value should never be null; when I write “?->”, I am stating that I > expect that the LHS is sometimes null. Thus, my code is documented in a > very concise way (between zero and one character), which is an aid for any > future reader (including myself). > > Aside: The name “nullsafe” is misleading. The operator is not about > safety, it is about handling null values in a concise way. In fact, in some > circumstances, sweeping an unexpected null value under the rug may be > totally unsafe. > > —Claude
