From: ruby-core@... Date: 2017-11-28T04:34:40+00:00 Subject: [ruby-core:83905] [Ruby trunk Feature#11816] Partial safe navigation operator Issue #11816 has been updated by marcandre (Marc-Andre Lafortune). Tracker changed from Bug to Feature ruby -v deleted (preview 2) Backport deleted (2.1: DONTNEED, 2.2: DONTNEED, 2.3: UNKNOWN) Matz, did you get a chance to consider the precedence of `&.`? As a reminder, there's currently no real use for `foo&.bar.baz` or similar. We are forced to write `foo&.bar&.baz` even though this could introduce unwanted errors, e.g. if `bar` was erroneously returning `nil`. I still believe that my proposal https://bugs.ruby-lang.org/issues/11816#note-6 is the right one. Thanks for the consideration. ---------------------------------------- Feature #11816: Partial safe navigation operator https://bugs.ruby-lang.org/issues/11816#change-67955 * 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: