Bug #11659: Strange behavior setting previously-undefined local variables with a statement modifier

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[mwpastore (Mike Pastore)]

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?

http://stackoverflow.com/questions/33537059/unless-defined-is-not-working-in-my-code

[Hanmac (Hans Mackowiak)]

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

[mwpastore (Mike Pastore)]

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.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Rejected