[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70299] [Ruby trunk - Bug #10856] Splat with empty keyword args gives unexpected results
From:
i@...
Date:
2015-08-10 12:27:38 UTC
List:
ruby-core #70299
Issue #10856 has been updated by Tymon Tobolski.
Hi Matz,
I think I just found a real-world use-case for exactly this issue - please take a look at the (simplified) example below.
~~~ruby
class Dispatcher
def call(event, args)
public_send(event, **args)
end
def first_event(myarg:)
# ...
end
def second_event
# ...
end
end
~~~
And the call site looks like this:
~~~ruby
disp = Dispatcher.new
disp.call(params[:event], params[:args])
~~~
Then we can observe:
~~~ruby
disp.call(:first_event, {myarg: 123}) # => passes correctly, all good
disp.call(:first_event, {}) # => missing keyword: myarg - exactly what I'd expect
disp.call(:first_event, {myarg: 123, other: "foo"}) # => unknown keyword: other - exactly what I'd expect
disp.call(:second_event, {}) # => wrong number of arguments (1 for 0) - this /should/ just pass without error
~~~
So, in case the `params[:args]` is empty we would expect to either get a "missing keyword" exception or simply valid method execution when such param is not required.
Please let me know what do you think about it.
----------------------------------------
Bug #10856: Splat with empty keyword args gives unexpected results
https://bugs.ruby-lang.org/issues/10856#change-53720
* Author: Sean Griffin
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v: ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin13]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
When keyword args are passed to a method with splat, and there are no keyword args, an empty hash is sent. I would expect no argument to be given, same as splat with an empty array. For example:
def foo
end
foo(**{})
This causes an argument error, as an empty hash is passed. I would expect the same behavior as
def foo
end
foo(*[])
--
https://bugs.ruby-lang.org/