[ruby-core:84105] [Ruby trunk Feature#11816] Partial safe navigation operator

Issue #11816 has been updated by phluid61 (Matthew Kerwin).


marcandre (Marc-Andre Lafortune) wrote:
> phluid61 (Matthew Kerwin) wrote:
> > If there was a way to explicitly signal the end of the "infectious nil" I'd probably find it useful
> 
> There is one way, and it is the same as with all the cases where the precedence doesn't go the way you want it: parentheses.
> 
>     (foo || bar) && baz
>     (friend&.message).blank?
> 
> The whole point of precedence is to allow writing things simply and without parentheses most of the time.

Hmm, that's *almost* right, but in my mind it still doesn't quite fit.  I think the problem I have is the expectation that modifying one message dispatch (`.` → `&.`) shouldn't affect subsequent messages. If you want to affect the dispatch of a group of messages you should use a scoping construct, and operator precedence (even with parens) isn't *scope*.  That's why `foo&.instance_eval{bar.baz}` feels right, even if it's ugly.

Perhaps I am alone in seeing `&.` as an armoured `.`, not an executing `&&`. (Despite the fact that `false&.! == true`)

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

* Author: marcandre (Marc-Andre Lafortune)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
----------------------------------------
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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>