Skip to content

Do not autosplat array in block call just because keywords accepted - #5665

Merged
jeremyevans merged 2 commits into
ruby:masterfrom
jeremyevans:no-autosplat-kw-18633
Mar 30, 2022
Merged

Do not autosplat array in block call just because keywords accepted#5665
jeremyevans merged 2 commits into
ruby:masterfrom
jeremyevans:no-autosplat-kw-18633

Conversation

@jeremyevans

Copy link
Copy Markdown
Contributor

If the block only accepts a single positional argument plus keywords,
then do not autosplat. Still autosplat if the block accepts more
than one position argument in addition to keywords.

Autosplatting a single positional argument plus keywords made sense
in Ruby 2, since a final positional hash could be used as keywords,
but it does not make sense in Ruby 3.

Fixes [Bug #18633]

@eregon eregon left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

@jeremyevans
jeremyevans force-pushed the no-autosplat-kw-18633 branch from f1e59d2 to 3dd40ff Compare March 24, 2022 17:42
@jeremyevans
jeremyevans requested a review from nobu March 24, 2022 17:42
If the block only accepts a single positional argument plus keywords,
then do not autosplat.  Still autosplat if the block accepts more
than one position argument in addition to keywords.

Autosplatting a single positional argument plus keywords made sense
in Ruby 2, since a final positional hash could be used as keywords,
but it does not make sense in Ruby 3.

Fixes [Bug #18633]
@jeremyevans
jeremyevans force-pushed the no-autosplat-kw-18633 branch from 3dd40ff to c32f435 Compare March 24, 2022 17:47
ruby_version_is ''..."3.2" do
it "autosplats single argument to required arguments when a keyword rest argument is present" do
m([1, 2]) { |a, **k| [a, k] }.should == [1, {}]
end

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it is considered a bug, shouldn’t it be a ruby_bug guard?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eregon can you advise?

@eregon eregon Mar 30, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ruby_bug mostly makes sense when the change will be backported, but it will probably not be backported here (https://bugs.ruby-lang.org/issues/18633#note-2).
The main difference between ruby_bug and ruby_version_is is what should be the behavior of other Ruby implementations.
In this case I think it's probably better for other Ruby implementations to follow the 3.0 & 3.1 behavior (assuming the fix is not backported), and so ruby_version_is seems better for compatibility of these other Ruby implementations (as long as they target 3.0/3.1).
It's also not hard to follow this behavior (I did it in TruffleRuby), although it does look like a weird exception.

So I think ruby_version_is + # https://bugs.ruby-lang.org/issues/18633 above is the best here.

Comment thread spec/ruby/language/block_spec.rb
@jeremyevans
jeremyevans merged commit fbaadd1 into ruby:master Mar 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants