Bug #20858: multiple parallel assignments are inconsistent

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[daveola (David Stellar)]

I may have terminology wrong, so apologies. For this bug I'm going to use "multiple assignment" to refer to using multiple assignment operators in a line, such as:

a = b = c = 1

And then parallel assignment to refer to doing multiple assignments at the same time using tuples, such as:

a,b = 1, 2

Unfortunately combining these is inconsistent. First of all, just doing this:

a,b = c,d = 3,4

Gives us: "undefined local variable or method `c' for main (NameError)"

So if we work around that by defining all our variables, we then get unexpected results:

a = b = c = d = 'foobar'

a,b = c,d = 3,4

puts "Got:  a=#{a} b=#{b} and c=#{c} d=#{d}"
# Got:  a=foobar b=3 and c=foobar d=3

c,d = 3,4
a,b = c,d

puts "Got:  a=#{a} b=#{b} and c=#{c} d=#{d}"
# Got:  a=3 b=4 and c=3 d=4

I can imagine that if multiple parallel assignment is not supported that a,b will not get set properly, but it does not follow that c would be undefined by the expression.

[mame (Yusuke Endoh)]

Currently, a, b = c, d = 3, 4 is interpreted as a, b = c, (d = 3, 4). Whether it is good or not.

[daveola (David Stellar)]

mame (Yusuke Endoh) wrote in #note-1:

Currently, a, b = c, d = 3, 4 is interpreted as a, b = c, (d = 3, 4). Whether it is good or not.

Ah - that's a good point. So it can be fixed with: a, b = (c, d = 3, 4)
I didn't see that possibility. Is there a clear reason why it's interpreted like this?

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

The a,b = c,(d=3,4) is the natural combination of the current rules. Changing this could make syntax even more complex.
I don't want to change the syntax here.

Matz.