Bug #11659

Strange behavior setting previously-undefined local variables with a statement modifier

Added by mwpastore (Mike Pastore) over 4 years ago. Updated about 1 year ago.

Target version:
ruby -v:
ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]


Consider a previously-undefined local variable var1:

irb(main):001:0> if defined?(var1).nil?; var1 = 'default'; end; var1
=> "default"

Consider previously-undefined local variables var1 and var2:

irb(main):001:0> var2 = 'default' if defined?(var1).nil?; var2
=> "default"

Consider a previously-undefined local variable var3:

irb(main):001:0> var3 = 'default' if true; var3
=> "default"

Consider a previously-undefined local variable var4:

irb(main):001:0> var4 = 'default' if defined?(var4).nil?; var4
=> nil

Oops! Why is var4 nil? Logically, considering the prior examples, it should be 'default'. Or are we missing something?

Updated by Hanmac (Hans Mackowiak) over 4 years ago

var2 = 'default' if defined?(var1).nil?; var2

because you got a typo for var2, see the var1 inside.

var4 = 'default' if defined?(var4).nil?; var4

the problem there is that var got defined from the parser before the code is run, so when it does check for defined, var4 is already defined

also checkout:

var = "ok" if false; var #=> nil

Updated by mwpastore (Mike Pastore) over 4 years ago

That's not a typo. :-) I wanted to intentionally compare and contrast between a scenario where the same variable was being checked and set (#2) and a scenario where two different variables are in play (#4).

I understand about the parser now, and in fact found another question/answer on SO that explains it in a similar manner. So it's not a bug, per se. It is kind of a Ruby "WTF", though, and in this humble Rubyist's opinion violates POLA pretty badly.


Updated by jeremyevans0 (Jeremy Evans) about 1 year ago

  • Status changed from Open to Rejected

Also available in: Atom PDF