[ruby-core:27267] Re: [Bug #2422] splat operator fails on array of 1 element

2009/12/21 katz bo <[e-mail]>

> Issue #2422 has been updated by katz bo.
>
>
> Dave B wrote:
> >Producing an empty array from a splatted empty array seems unproductive.
> Agreed.
>
> Tanaka Akira wrote:
> > 2009/12/21 katz bo <[e-mail]>:
> >> I personally think *[1, 2, 3] should be always unpacked first.
> >
> > Your way cannot interpret a = *[].
> >
> > a = *[]
> > a =
> >
> > It is not a valid Ruby statement.
>
> Why not think of this as a special case?
> There's always something special about zeros and nils in my shallow
> opinion. :P
>
> In fact, a = *[] should _exactly_ be a = IMHO. And strictly speaking, a =
> *[] should not be a valid syntax at all.
> But, this is Ruby!
>
> What does Ruby do with a = *[] ? Let me illustrate an IMO proper way:
> Ruby looks at *[] and goes, "Fine, let me unpack it."
> Ruby unpacks *[].
> Then Ruby goes, "Nothing? But I can't _carry_ <nothing>! No.. not in an
> assignment! Wait.. Let's do it!"
> Ruby marks it as nil.
>
> One of the reasons why I think this special case should be handled this
> way, is the way Ruby handles parallel assignments:
> a, b = [1] # => [1]
> p a # => 1
> p b # => nil
> This is not the case, for example, in python. (It spits "ValueError: need
> more than 1 value to unpack" when you do a, b = [1]).
> Since Ruby auto-pads the out-of-range elements as nil, we have a good
> reason to make Ruby automatically handle a = *[] in this way.
>
> I also have a vague observation that the splatted array is actually dealt
> differently by the internal Ruby in some cases. Assignment is such a case.
>
> # COMMAND    # OUTPUT # RETURN # NOTES
> p            #        # => nil
> p *[]        #        # => nil # Fits very well in my "unpack first" theory
> p nil        # nil    # => nil
> a = *[]; p a # []     # => []  # ruby 1.9; should both be nil IMO
> a =* []; p a # []     # => []  # ruby 1.9; should both be nil IMO; the
> space between * and [ is allowed!
>
> Additionally, I find `return' fails my expectations in a similar way
> assignment does:
>
> def foo; return *[]; end;       foo # => []  # ruby 1.9; I have doubt: nil
> or []?
> def bar; return *[1]; end;      bar # => [1] # ruby 1.9; I was expecting 1
> def baz; return *[],*[1]; end;  baz # => [1]
> def ban; return *[1],*[2]; end; ban # => [1, 2]
> def boo; return *[1,2]; end;    boo # => [1, 2]
>
> We know that return packs multiple parameters into an array. This, combined
> with my "unpack first" theory, makes me think the first two results are not
> correct. But I don't know. Can't test it with ruby 1.8 since I don't have it
> installed.
>
> Can somebody post the result to the code above for ruby 1.8?
>
>
Here it is:
COMMAND # 1.9 vs 1.8

p                # => nil
p *[]            # => nil
p nil            # => nil
a = *[]; p a # => [] vs nil
a =* []; p a # => []  vs nil

These 2 last look very weird.

---------

def foo; return *[]; end; foo # => [] vs nil
def bar; return *[1]; end; bar # => [1] vs 1

def baz; return *[],*[1]; end;  baz # => [1] vs SyntaxError: compile error
(
    (irb):4: syntax error, unexpected tSTAR, expecting tAMPER
    def baz; return *[],*[1]; end;  baz
                         ^
    (irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'
    def baz; return *[],*[1]; end;  baz
                             ^
)

def ban; return *[1],*[2]; end; ban # => [1, 2] vs SyntaxError: compile
error
(
   (irb):4: syntax error, unexpected tSTAR, expecting tAMPER
   def ban; return *[1],*[2]; end; ban # => [1, 2]
                         ^
   (irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'
   def ban; return *[1],*[2]; end; ban # => [1, 2]
                             ^
)


def boo; return *[1,2]; end; boo # => [1, 2] vs [1, 2]

So here we clearly see how 1.9 is more 'safe' ...