From: shugo@... Date: 2015-12-17T03:14:06+00:00 Subject: [ruby-core:72203] [Ruby trunk - Bug #11816] Partial safe navigation operator Issue #11816 has been updated by Shugo Maeda. Marc-Andre Lafortune wrote: > Matz, did you get a chance to think about the "precedence" level of `&.`? It would be harder to change after christmas... Is it really hard to change after the release of Ruby 2.3? IMHO, the current behavior of `x&.foo.bar` is useless, so users have to use `x&.foo&.bar` instead. Even if the behavior of `x&.foo.bar` is changed as you expect, `x&.foo&.bar` still works, and users can switch from `x&.foo&.bar` to `x&.foo.bar` gradually. Please tell me if I miss anything. I'm not against the proposal itself, but there's no enough time left.... FYI, the behavior of Groovy's `?.` seems to be the same as Ruby's `&.`: ``` $ groovy -e 'x = null; print(x?.foo.bar)' Caught: java.lang.NullPointerException: Cannot get property 'bar' on null object java.lang.NullPointerException: Cannot get property 'bar' on null object at script_from_command_line.run(script_from_command_line:1) ``` Please tell me if someone knows the behavior in C#. ---------------------------------------- Bug #11816: Partial safe navigation operator https://bugs.ruby-lang.org/issues/11816#change-55614 * Author: Marc-Andre Lafortune * Status: Open * Priority: Normal * Assignee: Yukihiro Matsumoto * ruby -v: preview 2 * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- I'm extremely surprised (and disappointed) that, currently: 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 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/