Hey, On Tue, Nov 3, 2020 at 9:11 PM Marco Pivetta <ocram...@gmail.com> wrote: > Overall, "null safe" can be very dangerous if made the default. > > Here's a scenario where I'd never want "null safe" behaviour (which does > anything but introducing safety): > > ```php > $accounts->get($receiver) > ->addFunds( > $accounts->get($sender) > ->detractFunds($amount) > ); > ``` > > In the above scenario, if the first `$accounts->get()` call returns `null` > for any reason, you may actually destroy money (funds detracted, but never > added to another account). > > The example is simplistic, but it shows that "null safe" is everything but > "safe", and it must instead be used only where it absolutely makes sense to > suppress null reference errors. > > Similar behaviour can be observed around cast operators, which are too lax > for most businesses logic: > https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229 > > Safe = crashes when it should crash.
I agree. The goal here is not to never encounter a crash. The goal is to make dealing with known potential null values easier. Crashing is the safer behavior when something happens you might not have taken into account. Honestly, in hindsight "nullsafe" might not have been the best term. I adopted the term from the previous RFC. There are actually quite a few other languages that use the word "safe" for this feature. https://en.wikipedia.org/wiki/Safe_navigation_operator The most obvious alternative would be optional chaining. I'd suggest renaming it but I don't think that's viable at this point because those token names might already be used in various tools and extensions. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
