On Thu, Feb 2, 2012 at 8:03 AM, Josh Cheek <josh.cheek / gmail.com> wrote:
> Could you just write what you expect the evaluation to be in each of these
> cases?
>
> a, b = 1, 1
> a, b = 1, nil
> a, b = nil, 1
> a, b = nil, nil
>
> I'd expect return values of [1, 1], [1, nil], [nil, 1], [nil, nil] which
> are all true.

Yes, I expect what you expect.

Also,

  a, b = nil         # a and b both get the value nil

> Now does this change when the RHS is an array instead of two values?
> For example, would `a, b = [1, 1]` return a different value than `a, b =
> [1, 1]`?

No, because you wrote them exactly the same!

Assuming you meant to compare these two:

  a, b = 1, 1
  a, b = [1, 1]

then I expect them to behave exactly the same.  I can see why you
expect it to set a to [1,1] and b to nil, but that's just not the way
it is.  If I'm not wrong, Ruby actually converts the first line above
into the second line behind the scenes.  After all, that's precisely
how you return multiple values from a method, or at least give the
appearance of doing so.

  def two_values(x)
    [x*2, x^2]
  end

  a, b = two_values(5)

From faint memory, to achieve the same thing in Perl you must wrap the
LHS in an array.  Ruby's equivalent would be

  [a, b] = two_values(5)    # This doesn't work in Ruby, and it's not missed.

> Your example seems particularly devious in that it only has one value on
> the RHS of the assignment.

No it doesn't.  That's not a value, per se, it's a method call.  The
method call returns either an array, which assigns the two variables
and activates the "if" branch, or nil, which activates the "else"
branch.

I didn't approach this being devious or thinking it would be at all
controversial.  I simply have a good intuition for assignment in Ruby.

> This means that the second argument will be
> assigned nil (because there is no value for it),

No.  Try this in irb:

  if _ = (a, b = [5,2,16,100])
    puts a + b
  end

And this.

  a, b = nil
  a, b = 1
  a, b = 1, 2
  a, b = [1, 2]
  a, b = [1,2,3,4,5]

  a, *b = nil
  a, *b = 1
  a, *b = 1, 2
  a, *b = [1, 2]
  a, *b = [1,2,3,4,5]

and see what these assignment operators return and what values get set
to a and b.

> [...]
>
> There are so many nuanced ruby edge cases one must know (and then must also
> know the implementation of how it is being returned) to understand that
> example that I think it has more overhead than it is worth.

There isn't a single nuance [1]; it all follows from understanding
parallel assignment in Ruby.  I didn't go out of my way to learn that.
 It must have been in one of the early Ruby books I read, or
something, and something I use all the time (especially multiple
returns from methods).

[1] in 1.9.3.  The earlier versions have the nuance of

  a, b = nil      # Returns [nil] instead of nil.

That pre-1.9.3 behaviour is contrary to what I've always expected and
I'm glad to see it corrected.  I can only surmise that the syntax
error "multiple assignment in conditional" is a hangover from those
days as a (fair) warning that it's not going to do what you expect,
and no good can come of it.  They've changed the behaviour, but left
the completely unnecessary syntax error.

Gavin