[#84280] [Ruby trunk Bug#14181] hangs or deadlocks from waitpid, threads, and trapping SIGCHLD — nobu@...
Issue #14181 has been updated by nobu (Nobuyoshi Nakada).
3 messages
2017/12/15
[#84398] [Ruby trunk Bug#14220] WEBrick changes - failures on MSWIN, MinGW — Greg.mpls@...
Issue #14220 has been reported by MSP-Greg (Greg L).
3 messages
2017/12/22
[#84472] Re: [ruby-dev:50394] [Ruby trunk Bug#14240] warn four special variables: $; $, $/ $\ — Eric Wong <normalperson@...>
Shouldn't English posts be on ruby-core instead of ruby-dev?
3 messages
2017/12/26
[ruby-core:84057] [Ruby trunk Feature#11816] Partial safe navigation operator
From:
zn@...
Date:
2017-12-02 08:47:10 UTC
List:
ruby-core #84057
Issue #11816 has been updated by znz (Kazuhiro NISHIYAMA).
marcandre (Marc-Andre Lafortune) wrote:
> 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 found real use case in [【アンチパターン】全部nil(null)かもしれない症候群](https://qiita.com/jnchito/items/6161647b624fb51cb815).
```ruby
if friend&.message.blank?
```
----------------------------------------
Feature #11816: Partial safe navigation operator
https://bugs.ruby-lang.org/issues/11816#change-68143
* 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:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>