[#72745] [Ruby trunk - Misc #11876] [Closed] Scheduled maintenance 2016/01/01 — shibata.hiroshi@...
Issue #11876 has been updated by Hiroshi SHIBATA.
shibata.hiroshi@gmail.com wrote:
[#72824] [Ruby trunk - Bug #11973] IO#advise should raise NotImplementedError on platforms that do not support that call — git@...
Issue #11973 has been updated by Chuck Remes.
[#72954] [Ruby trunk - Feature #12010] [Assigned] Exclude dot and dotdot from Dir#each — naruse@...
Issue #12010 has been reported by Yui NARUSE.
naruse@airemix.jp wrote:
[#73313] [Ruby trunk - Bug #12007] [Open] Newly added Unicode data file doesn't get downloaded — shugo@...
Issue #12007 has been updated by Shugo Maeda.
[#73372] [Ruby trunk - Misc #12004] Code of Conduct — benton@...
Issue #12004 has been updated by Benton Barnett.
On Sun, Jan 24, 2016 at 5:13 PM, <benton@bentonbarnett.com> wrote:
[#73421] [Ruby trunk - Misc #12004] Code of Conduct — nekocat432@...
Issue #12004 has been updated by Ruby Dino.
I’m sorry, but this, like the code of merit, is merely a derailing tactic.
On 2016/01/26 01:32, Austin Ziegler wrote:
On Tue, Jan 26, 2016 at 12:25 AM, Martin J. Dürst <duerst@it.aoyama.ac.jp>
[#73491] [Ruby trunk - Misc #12004] Code of Conduct — git@...
Issue #12004 has been updated by Chuck Remes.
They will never provide any numbers because they are not engineers and they
Coraline is a panelist on Ruby rogues and a very well respected member of
OK, sorry for previous comment. Let's try this way.
On Tue, Jan 26, 2016 at 5:15 PM, Andrew Kirilenko <
[#73558] [Ruby trunk - Misc #12004] Code of Conduct — andrew.kirilenko@...
Issue #12004 has been updated by Andrew Kirilenko.
Andrew, please stop digging. Your hole is only getting deeper.
>Andrew, please stop digging. Your hole is only getting deeper.
[#73586] [Ruby trunk - Misc #12004] Code of Conduct — andrew@...
Issue #12004 has been updated by Andrew Vit.
[#73593] [Ruby trunk - Bug #12034] RegExp does not respect file encoding directive — nobu@...
Issue #12034 has been updated by Nobuyoshi Nakada.
[ruby-core:72769] [Ruby trunk - Bug #11967] Mixing kwargs with optional parameters changes way method parameters are parsed
Issue #11967 has been updated by Martin D端rst.
Assignee set to Yukihiro Matsumoto
This looks like a spec issue, so I have assigned it to Matz. I can see arguments for both ways, the current one and the one proposed by Markus. But we can't have it both ways :-(.
----------------------------------------
Bug #11967: Mixing kwargs with optional parameters changes way method parameters are parsed
https://bugs.ruby-lang.org/issues/11967#change-56015
* Author: Markus Doits
* Status: Open
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* ruby -v: ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: UNKNOWN
----------------------------------------
I have the following method:
def test(first_param = nil, keyword_arg: nil)
puts "first_param: #{first_param}"
puts "keyword_arg: #{keyword_arg}"
end
All the following calls do what I expect them to do:
test(:something)
#=> first_param: something
# keyword_arg:
test(nil, keyword_arg: :keyword_arg)
#=> first_param:
# keyword_arg: keyword_arg
test({ first_param: :is_a_hash }, keyword_arg: :is_still_working)
#=> first_param: {:first_param=>:is_a_hash}
# keyword_arg: is_still_working
But omitting the optional `keyword_arg` and passing a hash as first argument gives me an error:
test(first_param: :is_a_hash)
#=> test.rb:1:in `test': unknown keyword: first_param (ArgumentError)
# from test.rb:12:in `<main>'
I'd expect it to set `first_param` to `{ first_param: :is_hash }` and `keyword_arg` being `nil`.
It seems it is interpreting every hash as keyword arg:
test(keyword_arg: :should_be_first_param)
#=> first_param:
# keyword_arg: should_be_first_param
This should have set `first_param` to `{ keyword_arg: :should_be_first_param }`, leaving `keyword_arg` `nil` in my opinion.
Making the first parameter *mandatory* and everything works like I'd expect to:
def test(first_param, keyword_arg: nil)
puts "first_param: #{first_param}"
puts "keyword_arg: #{keyword_arg}"
end
test(first_param: :is_a_hash)
#=> first_param: {:first_param=>:is_a_hash}
# keyword_arg:
test(keyword_arg: :should_be_first_param)
#=> first_param: {:keyword_arg=>:should_be_first_param}
#=> keyword_arg:
I'd expect making a parameter optional does not change the way parameters are parsed.
Is this a parser oddity or expected behaviour?
--
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>