Issue #11816 has been updated by marcandre (Marc-Andre Lafortune).


> The &. operator has pretty well-defined semantics by now and changing it may break some existing code.

Any change may break some existing code. Given the fact that `foo&.bar.baz` have basically no use whatsover, it is difficult to see what functioning code could be broken though. Let's also think of how many potential bugs we are creating by forcing Rubyists to write `foo&.bar&.baz` when that's not what they mean.

----------------------------------------
Feature #11816: Partial safe navigation operator
https://bugs.ruby-lang.org/issues/11816#change-85097

* Author: marcandre (Marc-Andre Lafortune)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
I'm extremely surprised (and disappointed) that, currently:

```ruby
x = nil
x&.foo.bar # => NoMethodError: undefined method `bar' for nil:NilClass
```

To make it safe, you have to write `x&.foo&.bar`. But if `foo` is never supposed to return `nil`, then that code isn't "fail early" in case it actually does. `nil&.foo.bar` is more expressive, simpler and is perfect if you want to an error if `foo` returned `nil`. To actually get what you want, you have to resort using the old form `x && x.foo.bar`...

In CoffeeScript, you can write `x()?.foo.bar` and it will work well, since it gets compiled to

```js
if ((_ref = x()) != null) {
  _ref.foo.bar;
}
```

All the discussion in #11537 focuses on `x&.foo&.bar`, so I have to ask:

Matz, what is your understanding of `x&.foo.bar`?

I feel the current implementation is not useful and should be changed to what I had in mind. I can't see any legitimate use of `x&.foo.bar` currently.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>