But this is about more than just assignment, it is also about method calls
vs. method defs.

"Robert Klemme" <bob.news / gmx.net> wrote

> > Why does
> >    def f; 1, 2, 3; end
>
> You sure, that this is the code you use?

My mistake, it was: def f; return 1, 2, 3; end

> It's an optimization to save typing: if there are multiple values and on
one
> side there is only one value "*" is automatically prepended:

Ah. Unfortunate decision, because ...

x = 1, 2, 3 #=> x = [1, 2, 3]
*x = 1, 2, 3 #=> x = [1, 2, 3]

def f(x); puts x; end
    f(1, 2, 3) #=> ArgError: wrong num. of args
    f([1, 2, 3]) #=> [1, 2, 3]

def g(*x); puts x; end
    g(1, 2, 3) #=> [1, 2, 3]

> >> x, = f

Ouch! I did not know that.  But
    def f(x,); end #=> error.
i.e. There is no such ',' syntax for method or proc parameters, just '*'.

Method calls establish bindings. *, **, and & are nicely consistent and
symmetric in
    method call: ... f(*x)
        vs.
    method definition: def f(*x); end
Since both method call and assignment establish variable bindings, I would
suggest that:
* on lhs vs. rhs of assignement should parallel * on call vs. def
** on lhs vs. rhs of assignment (if allowed) should parallel ** on call vs.
def
I'd say the same for '&', but can't think of a meaningful '&x = foo'.

> IMHO we have to judge the costs of this change (broken code, confused
coders
> :-)) vs. what we gain (more consistency).  Dunno on what side the balance
> will come down though.

Imho, a design decision that saves typing a single *, and as a result makes
binding variables via the assigment operation inconsistent with binding
variables via a method call, is one that _should_ be changed for 2.0.

What do other Rubyists think of this proposal (assuming there was no issue
of backward compatibility) ?