Feature #8190: Truly parallel assignment

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[Lavir_the_Whiolet (Lavir the Whiolet)]

=begin
i = 0
s = [1,2,3]
i, s[i] =s[i], 7
p s
#=> [1, 7, 3]

s is expected to be [7, 2, 3].
=end

[wardrop (Tom Wardrop)]

=begin
Hmm, yeah that request seems reasonable. Right now it seems to be assigning left-to-right. So (({i})) is assigned (({s[i]})), making (({i})) equal to (({1})), only then is (({s[i]})) evaluated and assigned (({7})) as if it's a separate expression on a new line.

Could be a difficult change to make at least in terms of backwards compatibility, but the suggested behaviour is less surprising than the current behavior in my opinion.
=end

[marcandre (Marc-Andre Lafortune)]

• Category set to core
• Assignee set to matz (Yukihiro Matsumoto)

My first reflex would be to say "don't write code like this".

Do you have an actual use case?

FWIW, CoffeeScript handles this case the same way as MRI does.

[nobu (Nobuyoshi Nakada)]

The evaluation obeys the left-to-right order.
It doesn't seem like a bug to me.

[Hanmac (Hans Mackowiak)]

=begin

((%Lavir_the_Whiolet when you change this you will break code like%))

(({a,b = b,a}))

wich is a feature of ruby

I think it's good that Lavir is bringing this up, although I share MA's
feeling. I don't see how his proposal it would break "a, b = b, a". On the
contrary, "a, b = b, a" would only break if the assignment indeed worked
sequentially looks questioningly @ wardrop & nobu. I do not know whether
this slightly counterintuitive behavior is a problem of that requires
change in the code behavior, or just better documentation to remove the
feeling of surprise, but I do not regard design by jury the best approach
in this case.

[matz (Yukihiro Matsumoto)]

• Category deleted (core)
• Status changed from Open to Rejected

As Nobu stated the evaluation order goes from left to right.
And if you change this, you will introduce incompatibility.

Matz.