Hm, yes. If the `get()` method can return `null`, then it is a problem. Currently `null` is abused to indicate that value was not found. `NotFoundException` should be thrown instead.
But.. yeah, we can't just use `nullsafe` by default because of abuse of `null`. On Tue, Nov 3, 2020 at 10:11 PM Marco Pivetta <ocram...@gmail.com> wrote: > Heya, > > On Tue, Nov 3, 2020, 17:38 Eugene Sidelnyk <zsidel...@gmail.com> wrote: > >> 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? >> > > 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. > >>