[#71815] [Ruby trunk - Bug #11768] [Open] Add a polymorphic inline cache — tenderlove@...
Issue #11768 has been reported by Aaron Patterson.
tenderlove@ruby-lang.org wrote:
On Thu, Dec 03, 2015 at 10:51:08PM +0000, Eric Wong wrote:
Aaron Patterson <tenderlove@ruby-lang.org> wrote:
[#71818] [Ruby trunk - Feature #11769] [Open] optimize case / when for `nil` — tenderlove@...
Issue #11769 has been reported by Aaron Patterson.
tenderlove@ruby-lang.org wrote:
[#71931] [Ruby trunk - Feature #11786] [Open] [PATCH] micro-optimize case dispatch even harder — normalperson@...
Issue #11786 has been reported by Eric Wong.
Oops, I forgot to free the table when iseq is destroyed :x
On 2015/12/08 12:43, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
On 2015/12/08 13:53, Eric Wong wrote:
[#72028] [Ruby trunk - Feature #11405] [Assigned] [PATCH] hash.c: minor speedups to int/fixnum keys — mame@...
Issue #11405 has been updated by Yusuke Endoh.
mame@ruby-lang.org wrote:
[#72045] Ruby 2.3.0-preview2 Released — "NARUSE, Yui" <naruse@...>
We are pleased to announce the release of Ruby 2.3.0-preview2.
Please add your optimizations before RC1.
SASADA Koichi <ko1@atdot.net> wrote:
On 2015/12/11 18:06, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#72069] [Ruby trunk - Feature #11405] [PATCH] hash.c: minor speedups to int/fixnum keys — mame@...
Issue #11405 has been updated by Yusuke Endoh.
[#72115] Re: [ruby-cvs:60264] duerst:r53112 (trunk): * enc/ebcdic.h: new dummy encoding EBCDIC-US — "U.NAKAMURA" <usa@...>
Hi,
On 2015/12/14 22:34, U.NAKAMURA wrote:
Hi,
[ruby-core:72214] [Ruby trunk - Bug #11816] Partial safe navigation operator
Issue #11816 has been updated by Shugo Maeda.
Yusuke Endoh wrote:
> > Is it really hard to change after the release of Ruby 2.3?
>
> As Marc-Andre stated in https://bugs.ruby-lang.org/issues/11816#note-7, it will bring incompatibility. If we may change the spec in future, I think we should explicitly state the possibility in doc and release message. Also, it might be a good idea to mark the feature as "experimental".
It would be better if Matz would like to change the behavior in future.
> Another idea for the proposal: how about propagating `&.` as long as explicit method chain (that uses `.` literally) continues?
>
> ~~~~
> x&.foo * 42 == (x&.foo) * 42
> x&.foo.*(42) == (x&.foo&.*(42)) # strictly not equivalent in the case where #foo returns nil
> ~~~~
In my understanding, rather than `(x&.foo&.*(42))`, `x&.foo.*(42)` is equivalent to `x && x.foo.*(42)` except when `x` is `false`.
So, the phrase "propagating `&.`" is confusing, isn't it?
Anyway, your proposal sounds reasonable because `x&.foo * 42` is parsed as `(x && x.foo) * 42` rather than `x && (x.foo * 42)` in my brain.
However, the behavior like `(x && x.foo) * 42` seems to be useless for the same reason as the current behavior of `x&.foo.bar`, so there is a trade-off.
----------------------------------------
Bug #11816: Partial safe navigation operator
https://bugs.ruby-lang.org/issues/11816#change-55624
* 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/