Bug #8398
closedcase/when shouldn't try to evaluate all AND joined conditions if one of preceding was falsy
Description
=begin
Steps to reproduce:
case 1
when String && proc { |x| x.blah }
:something
else
:no
end
Here is how I thought it works: goes to the first 'when', evals the first condition ((({1 === String}))), sees it's false and proceeds to the next (({when})) (or (({else}))) and happily returns (({:no})).
As it turns out, even if one of AND joined conditions was false, ruby would still try to eval other conditions, and as soon as it calls the block with 1, (({NoMethodError})) gets thrown as there is no (({#blah})) on Integer.
I believe this is incorrect behavior and conditions with AND in case/when should behave like everywhere else.
=end
Updated by jeremyevans0 (Jeremy Evans) over 11 years ago
You probably think your case statement is translated to:
case
when (String === 1) && (proc { |x| x.blah } === 1)
:something
else
:no
end
I believe ruby actually translates it to:
case
when (String && proc { |x| x.blah }) === 1
:something
else
:no
end
As String is not false or nil, it's fairly obvious why proc is evaluated. As you can see, using && in case expressions with values doesn't generally make sense.
Note that if you don't provide a value for case, the short circuiting works as you expect:
case
when (String === 1) && proc{|x| p x} === 1
:yes
else
:no
end
I suppose ruby could be modified to do what you want, but it could break existing code. Note that for || expressions, there is already special case syntax for short circuiting:
case 1
when String, proc { |x| x.blah } # String === 1 || proc { |x| x.blah } === 1
:something
else
:no
end
Updated by nobu (Nobuyoshi Nakada) over 11 years ago
- Status changed from Open to Rejected