[#97678] [Ruby master Feature#16752] :private param for const_set — bughitgithub@...
Issue #16752 has been reported by bughit (bug hit).
5 messages
2020/04/02
[ruby-core:97876] [Ruby master Feature#11816] Partial safe navigation operator
From:
zverok.offline@...
Date:
2020-04-14 08:02:51 UTC
List:
ruby-core #97876
Issue #11816 has been updated by zverok (Victor Shepelev).
> Given the fact that `foo&.bar.baz` have basically no use whatsover, it is difficult to see what functioning code could be broken though
I can imagine some!
* Not from production, but it does not seem too obscure: `foo&.bar.nil?` would be `true` in the current implementation, and `nil` in "skip-the-rest" implementation.
* A bit more obscure, but this one is from real code: `find.some.array&.first.tap { |val| log.debug "nothing found" if val.nil? }`
* ... or `find_key_vaue_pair(hash)&.last.then { |val| val.nil? ? default : val }` (not just `||`, because `false` is acceptable value)
Obviously, all can be rewritten another way -- but obviously, all will be currently broken by the change proposed.
----------------------------------------
Feature #11816: Partial safe navigation operator
https://bugs.ruby-lang.org/issues/11816#change-85098
* 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>