https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112009-12-03T03:01:43ZRuby Issue Tracking SystemBackport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=71262009-12-03T03:01:43Zujihisa (Tatsuhiro Ujihisa)
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>=begin</p>
<p>=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=71282009-12-03T08:19:55Zdaz (Dave B)
<ul></ul><p>=begin<br>
Tanaka Akira (on ruby-core) wrote:</p>
<blockquote>
<p>On Thu, Dec 3, 2009 at 2:35 AM, Raul Parolari <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a> wrote:</p>
<blockquote>
<p>Bug <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: splat operator fails on array of 1 element (Rejected)" href="https://bugs.ruby-lang.org/issues/2422">#2422</a>: splat operator fails on array of 1 element<br>
<a href="http://redmine.ruby-lang.org/issues/show/2422" class="external">http://redmine.ruby-lang.org/issues/show/2422</a></p>
</blockquote>
<blockquote>
<p>In Ruby 1.9.1:</p>
<p>a, b = *[ 137, 271 ] # a = 137; b = 271 # (as expected)</p>
<p>a = *[ 137 ] # a = [137 ] # (should be 137 !)</p>
</blockquote>
<p>The Ruby 1.9 behavior is simplified and more consistent.</p>
<p>% ruby -ve '<br>
a = *[1,2,3]; p a<br>
a = *[1,2]; p a<br>
a = *[1]; p a<br>
a = *[]; p a'<br>
ruby 1.9.2dev (2009-09-24 trunk 25067) [i686-linux]<br>
[1, 2, 3]<br>
[1, 2]<br>
[1]<br>
[]</p>
<p>% ruby-1.8 -ve '<br>
a = *[1,2,3]; p a<br>
a = *[1,2]; p a<br>
a = *[1]; p a<br>
a = *[]; p a'<br>
ruby 1.8.8dev (2009-10-15 revision 25343) [i686-linux]<br>
[1, 2, 3]<br>
[1, 2]<br>
1<br>
nil</p>
<p>Ruby 1.9 doesn't handle zero or one element array specially.</p>
</blockquote>
<p>But Raul's example reveals <em>inconsistency</em> from 1.9 for a balanced LHS / RHS ...</p>
<p>puts 'ruby %s (%s) [%s]' % [RUBY_VERSION, RUBY_RELEASE_DATE, RUBY_PLATFORM]</p>
<p>a,b,c,d = *[1,2,3,4]<br>
p [a,b,c,d]</p>
<p>a,b,c = *[1,2,3]<br>
p [a,b,c]</p>
<p>a,b = *[1,2]<br>
p [a,b]</p>
<p>a = *[1]<br>
p [a]</p>
<p>=begin (output)</p>
<p>ruby 1.8.6 (2008-08-11) [i386-mswin32]<br>
[1, 2, 3, 4]<br>
[1, 2, 3]<br>
[1, 2]<br>
[1]</p>
<p>ruby 1.9.2 (2009-05-19) [i386-mswin32_90]<br>
[1, 2, 3, 4]<br>
[1, 2, 3]<br>
[1, 2]<br>
[[1]]</p>
<p>=end</p>
<p>a = *[1] (a = 1) results in a = [1]</p>
<p>--<br>
daz</p>
<p>=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=73722009-12-21T01:50:10Zkatz (katz bo)lolilolicon@gmail.com
<ul></ul><p>=begin<br>
I personally think *[1, 2, 3] should be always unpacked first.</p>
<p>a = *[1, 2, 3] #(unpack Array due to *) should be equal to:<br>
a = 1, 2, 3 #(as Ruby is very smart) is equal to: (this is really the tricky part)<br>
*a = 1, 2, 3 #which packs 1, 2, 3 into Array a. Hence is equal to<br>
a = [1, 2, 3]</p>
<p>a = *[1] #(unpack Array due to *) should be equal to:<br>
a = 1 #(again, Ruby is smart it won't read this as *a = 1)</p>
<p>a, b = *[1, 2] #the Array gets unpacked first, so we get:<br>
a, b = 1, 2 #this behaves identical to the next line:<br>
a, b = [1, 2] #Hence a = 1; b = 2</p>
<p>If my understanding is correct, then the 1.9 behavior is a bug(TM).</p>
<p>I'm a noob so don't expect me to know what I'm talking about :D.<br>
=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=73822009-12-21T15:48:19Zdaz (Dave B)
<ul></ul><p>=begin</p>
<p>Tanaka Akira wrote:</p>
<blockquote>
<p>2009/12/21 katz bo <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>I personally think *[1, 2, 3] should be always unpacked first.</p>
<p>a = *[1, 2, 3] #(unpack Array due to *) should be equal to:<br>
a = 1, 2, 3 #(as Ruby is very smart) is equal to: (this is really the tricky part)<br>
*a = 1, 2, 3 #which packs 1, 2, 3 into Array a. Hence is equal to<br>
a = [1, 2, 3]</p>
<p>a = *[1] #(unpack Array due to *) should be equal to:<br>
a = 1 #(again, Ruby is smart it won't read this as *a = 1)</p>
</blockquote>
<p>Your way cannot interpret a = *[].</p>
<p>a = *[]<br>
a =</p>
<p>It is not a valid Ruby statement.</p>
</blockquote>
<p>I would expect to see the value of the first element in the empty array<br>
as 1.8.6 provides ...</p>
<p>puts 'ruby %s (%s) [%s]' % [RUBY_VERSION, RUBY_RELEASE_DATE, RUBY_PLATFORM]</p>
<p>a = *[]<br>
p a</p>
<p>a = [][0]<br>
p a</p>
<a name="ruby-186-2008-08-11-i386-mswin32"></a>
<h1 >ruby 1.8.6 (2008-08-11) [i386-mswin32]<a href="#ruby-186-2008-08-11-i386-mswin32" class="wiki-anchor">¶</a></h1>
<a name="nil"></a>
<h1 >nil<a href="#nil" class="wiki-anchor">¶</a></h1>
<a name="nil-2"></a>
<h1 >nil<a href="#nil-2" class="wiki-anchor">¶</a></h1>
<a name="ruby-192-2009-05-19-i386-mswin32_90"></a>
<h1 >ruby 1.9.2 (2009-05-19) [i386-mswin32_90]<a href="#ruby-192-2009-05-19-i386-mswin32_90" class="wiki-anchor">¶</a></h1>
<a name=""></a>
<h1 >[]<a href="#" class="wiki-anchor">¶</a></h1>
<a name="nil-3"></a>
<h1 >nil<a href="#nil-3" class="wiki-anchor">¶</a></h1>
<p>I understood your last reply to me about "a, =" in multiple assignment<br>
with a single RHS but, to me, "a = 1" is multiple assignment with<br>
balanced (single) LHS/RHS.</p>
<p>Producing an empty array from a splatted empty array seems unproductive. ;)</p>
<p>daz</p>
<p>=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=73852009-12-21T19:08:29Zkatz (katz bo)lolilolicon@gmail.com
<ul></ul><p>=begin<br>
Dave B wrote:</p>
<blockquote>
<p>Producing an empty array from a splatted empty array seems unproductive.<br>
Agreed.</p>
</blockquote>
<p>Tanaka Akira wrote:</p>
<blockquote>
<p>2009/12/21 katz bo <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>I personally think *[1, 2, 3] should be always unpacked first.</p>
</blockquote>
<p>Your way cannot interpret a = *[].</p>
<p>a = *[]<br>
a =</p>
<p>It is not a valid Ruby statement.</p>
</blockquote>
<p>Why not think of this as a special case?<br>
There's always something special about zeros and nils in my shallow opinion. :P</p>
<p>In fact, a = *[] should <em>exactly</em> be a = IMHO. And strictly speaking, a = *[] should not be a valid syntax at all.<br>
But, this is Ruby!</p>
<p>What does Ruby do with a = *[] ? Let me illustrate an IMO proper way:<br>
Ruby looks at *[] and goes, "Fine, let me unpack it."<br>
Ruby unpacks *[].<br>
Then Ruby goes, "Nothing? But I can't <em>carry</em> ! No.. not in an assignment! Wait.. Let's do it!"<br>
Ruby marks it as nil.</p>
<p>One of the reasons why I think this special case should be handled this way, is the way Ruby handles parallel assignments:<br>
a, b = [1] # => [1]<br>
p a # => 1<br>
p b # => nil<br>
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]).<br>
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.</p>
<p>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.</p>
<a name="COMMAND-OUTPUT-RETURN-NOTES"></a>
<h1 >COMMAND # OUTPUT # RETURN # NOTES<a href="#COMMAND-OUTPUT-RETURN-NOTES" class="wiki-anchor">¶</a></h1>
<p>p # # => nil<br>
p *[] # # => nil # Fits very well in my "unpack first" theory<br>
p nil # nil # => nil<br>
a = <em>[]; p a # [] # => [] # ruby 1.9; should both be nil IMO<br>
a =</em> []; p a # [] # => [] # ruby 1.9; should both be nil IMO; the space between * and [ is allowed!</p>
<p>Additionally, I find `return' fails my expectations in a similar way assignment does:</p>
<p>def foo; return *[]; end; foo # => [] # ruby 1.9; I have doubt: nil or []?<br>
def bar; return *[1]; end; bar # => [1] # ruby 1.9; I was expecting 1<br>
def baz; return <em>[],</em>[1]; end; baz # => [1]<br>
def ban; return <em>[1],</em>[2]; end; ban # => [1, 2]<br>
def boo; return *[1,2]; end; boo # => [1, 2]</p>
<p>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.</p>
<p>Can somebody post the result to the code above for ruby 1.8?</p>
<p>=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=73872009-12-21T20:53:07ZEregon (Benoit Daloze)
<ul></ul><p>=begin<br>
2009/12/21 katz bo <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a></p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: splat operator fails on array of 1 element (Rejected)" href="https://bugs.ruby-lang.org/issues/2422">#2422</a> has been updated by katz bo.</p>
<p>Dave B wrote:</p>
<blockquote>
<p>Producing an empty array from a splatted empty array seems unproductive.<br>
Agreed.</p>
</blockquote>
<p>Tanaka Akira wrote:</p>
<blockquote>
<p>2009/12/21 katz bo <a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>:</p>
<blockquote>
<p>I personally think *[1, 2, 3] should be always unpacked first.</p>
</blockquote>
<p>Your way cannot interpret a = *[].</p>
<p>a = *[]<br>
a =</p>
<p>It is not a valid Ruby statement.</p>
</blockquote>
<p>Why not think of this as a special case?<br>
There's always something special about zeros and nils in my shallow<br>
opinion. :P</p>
<p>In fact, a = *[] should <em>exactly</em> be a = IMHO. And strictly speaking, a =<br>
*[] should not be a valid syntax at all.<br>
But, this is Ruby!</p>
<p>What does Ruby do with a = *[] ? Let me illustrate an IMO proper way:<br>
Ruby looks at *[] and goes, "Fine, let me unpack it."<br>
Ruby unpacks *[].<br>
Then Ruby goes, "Nothing? But I can't <em>carry</em> ! No.. not in an<br>
assignment! Wait.. Let's do it!"<br>
Ruby marks it as nil.</p>
<p>One of the reasons why I think this special case should be handled this<br>
way, is the way Ruby handles parallel assignments:<br>
a, b = [1] # => [1]<br>
p a # => 1<br>
p b # => nil<br>
This is not the case, for example, in python. (It spits "ValueError: need<br>
more than 1 value to unpack" when you do a, b = [1]).<br>
Since Ruby auto-pads the out-of-range elements as nil, we have a good<br>
reason to make Ruby automatically handle a = *[] in this way.</p>
<p>I also have a vague observation that the splatted array is actually dealt<br>
differently by the internal Ruby in some cases. Assignment is such a case.</p>
<a name="COMMAND-OUTPUT-RETURN-NOTES"></a>
<h1 >COMMAND # OUTPUT # RETURN # NOTES<a href="#COMMAND-OUTPUT-RETURN-NOTES" class="wiki-anchor">¶</a></h1>
<p>p # # => nil<br>
p *[] # # => nil # Fits very well in my "unpack first" theory<br>
p nil # nil # => nil<br>
a = <em>[]; p a # [] # => [] # ruby 1.9; should both be nil IMO<br>
a =</em> []; p a # [] # => [] # ruby 1.9; should both be nil IMO; the<br>
space between * and [ is allowed!</p>
<p>Additionally, I find `return' fails my expectations in a similar way<br>
assignment does:</p>
<p>def foo; return *[]; end; foo # => [] # ruby 1.9; I have doubt: nil<br>
or []?<br>
def bar; return *[1]; end; bar # => [1] # ruby 1.9; I was expecting 1<br>
def baz; return <em>[],</em>[1]; end; baz # => [1]<br>
def ban; return <em>[1],</em>[2]; end; ban # => [1, 2]<br>
def boo; return *[1,2]; end; boo # => [1, 2]</p>
<p>We know that return packs multiple parameters into an array. This, combined<br>
with my "unpack first" theory, makes me think the first two results are not<br>
correct. But I don't know. Can't test it with ruby 1.8 since I don't have it<br>
installed.</p>
<p>Can somebody post the result to the code above for ruby 1.8?</p>
</blockquote>
<p>Here it is:<br>
COMMAND # 1.9 vs 1.8</p>
<p>p # => nil<br>
p *[] # => nil<br>
p nil # => nil<br>
a = <em>[]; p a # => [] vs nil<br>
a =</em> []; p a # => [] vs nil</p>
<p>These 2 last look very weird.</p>
<hr>
<p>def foo; return *[]; end; foo # => [] vs nil<br>
def bar; return *[1]; end; bar # => [1] vs 1</p>
<p>def baz; return <em>[],</em>[1]; end; baz # => [1] vs SyntaxError: compile error<br>
(<br>
(irb):4: syntax error, unexpected tSTAR, expecting tAMPER<br>
def baz; return <em>[],</em>[1]; end; baz<br>
^<br>
(irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'<br>
def baz; return <em>[],</em>[1]; end; baz<br>
^<br>
)</p>
<p>def ban; return <em>[1],</em>[2]; end; ban # => [1, 2] vs SyntaxError: compile<br>
error<br>
(<br>
(irb):4: syntax error, unexpected tSTAR, expecting tAMPER<br>
def ban; return <em>[1],</em>[2]; end; ban # => [1, 2]<br>
^<br>
(irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'<br>
def ban; return <em>[1],</em>[2]; end; ban # => [1, 2]<br>
^<br>
)</p>
<p>def boo; return *[1,2]; end; boo # => [1, 2] vs [1, 2]</p>
<p>So here we clearly see how 1.9 is more 'safe' ...</p>
<p><br><br></p><div>2009/12/21 katz bo <span dir="ltr"><<a href="mailto:redmine@ruby-lang.org" class="email"></a><a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>></span><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Issue <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: splat operator fails on array of 1 element (Rejected)" href="https://bugs.ruby-lang.org/issues/2422">#2422</a> has been updated by katz bo.<br>
<div>
<br>
<br>
Dave B wrote:<br>
>Producing an empty array from a splatted empty array seems unproductive.<br>
</div>Agreed.<br>
<div>
<br>
Tanaka Akira wrote:<br>
> 2009/12/21 katz bo <<a href="mailto:redmine@ruby-lang.org" class="email">redmine@ruby-lang.org</a>>:<br>
>> I personally think *[1, 2, 3] should be always unpacked first.<br>
><br>
</div>
<div>> Your way cannot interpret a = *[].<br>
><br>
> a = *[]<br>
> a =<br>
><br>
> It is not a valid Ruby statement.<br>
<br>
</div>Why not think of this as a special case?<br>
There's always something special about zeros and nils in my shallow opinion. :P<br>
<br>
In fact, a = *[] should _exactly_ be a = IMHO. And strictly speaking, a = *[] should not be a valid syntax at all.<br>
But, this is Ruby!<br>
<br>
What does Ruby do with a = *[] ? Let me illustrate an IMO proper way:<br>
Ruby looks at *[] and goes, "Fine, let me unpack it."<br>
Ruby unpacks *[].<br>
Then Ruby goes, "Nothing? But I can't _carry_ <nothing>! No.. not in an assignment! Wait.. Let's do it!"<br>
Ruby marks it as nil.<br>
<br>
One of the reasons why I think this special case should be handled this way, is the way Ruby handles parallel assignments:<br>
a, b = [1] # => [1]<br>
p a # => 1<br>
p b # => nil<br>
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]).<br>
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.<br>
<br>
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.<br>
<br>
# COMMAND # OUTPUT # RETURN # NOTES<br>
p # # => nil<br>
p *[] # # => nil # Fits very well in my "unpack first" theory<br>
p nil # nil # => nil<br>
a = *[]; p a # [] # => [] # ruby 1.9; should both be nil IMO<br>
a =* []; p a # [] # => [] # ruby 1.9; should both be nil IMO; the space between * and [ is allowed!<br>
<br>
Additionally, I find `return' fails my expectations in a similar way assignment does:<br>
<br>
def foo; return *[]; end; foo # => [] # ruby 1.9; I have doubt: nil or []?<br>
def bar; return *[1]; end; bar # => [1] # ruby 1.9; I was expecting 1<br>
def baz; return *[],*[1]; end; baz # => [1]<br>
def ban; return *[1],*[2]; end; ban # => [1, 2]<br>
def boo; return *[1,2]; end; boo # => [1, 2]<br>
<br>
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.<br>
<br>
Can somebody post the result to the code above for ruby 1.8?<br>
<br>
</blockquote>
<div>
<br><span style="font-family: arial,helvetica,sans-serif;">Here it is:</span><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">COMMAND # 1.9 vs 1.8</span><br style="font-family: arial,helvetica,sans-serif;">
<br>
p # => nil<br>
p *[] # => nil<br>
p nil # => nil<br>
a = *[]; p a # => [] vs nil<br>
a =* []; p a # => [] vs nil<br><br>These 2 last look very weird.<br><br>---------<br><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">def foo; return *[]; end; foo # => [] vs nil</span><br style="font-family: arial,helvetica,sans-serif;">
<span style="font-family: arial,helvetica,sans-serif;">def bar; return *[1]; end; bar # => [1] vs 1</span><br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;">def baz; return *[],*[1]; end; baz # => [1] vs SyntaxError: compile error</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">( <br> (irb):4: syntax error, unexpected tSTAR, expecting tAMPER</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> def baz; return *[],*[1]; end; baz</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> ^</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> (irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> def baz; return *[],*[1]; end; baz</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ^</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">)</span><br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: arial,helvetica,sans-serif;">def ban; return *[1],*[2]; end; ban # => [1, 2] vs SyntaxError: compile error</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">(</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> (irb):4: syntax error, unexpected tSTAR, expecting tAMPER</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> def ban; return *[1],*[2]; end; ban # => [1, 2]</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> ^</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> (irb):4: syntax error, unexpected ';', expecting tCOLON2 or '[' or '.'</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> def ban; return *[1],*[2]; end; ban # => [1, 2]</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> ^</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">)</span><br style="font-family: courier new,monospace;">
<br style="font-family: courier new,monospace;"><br style="font-family: courier new,monospace;"><span style="font-family: arial,helvetica,sans-serif;">def boo; return *[1,2]; end; boo # => [1, 2] vs [1, 2]</span><br><br>
So here we clearly see how 1.9 is more 'safe' ...<br style="font-family: arial,helvetica,sans-serif;"><br style="font-family: arial,helvetica,sans-serif;"><span style="font-family: arial,helvetica,sans-serif;"></span><br>
</div>
</div>
<p>=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=73912009-12-22T01:02:32Zkatz (katz bo)lolilolicon@gmail.com
<ul></ul><p>=begin<br>
Thank you, Benoit Daloze.</p>
<p>I wrote:</p>
<blockquote>
<p>What does Ruby do with a = *[] ? Let me illustrate an IMO proper way:<br>
Ruby looks at *[] and goes, "Fine, let me unpack it."<br>
Ruby unpacks *[].<br>
Then Ruby goes, "Nothing? But I can't <em>carry</em> ! No.. not in an<br>
assignment! Wait.. Let's do it!"<br>
Ruby marks it as nil.</p>
</blockquote>
<p>As now I think I understand assignment better, I'd like to correct myself a bit:</p>
<p>foo = *[]<br>
When processing the above line, the Ruby interpreter does these things:</p>
<ol>
<li>First Ruby sees the left side of the assignment, i.e. foo =, and he points foo to nil.</li>
<li>Then Ruby tries to evaluate the rvalue. Looking at the *, Ruby unpacks the array [].</li>
<li>Ruby gets a little surprised when he finds it's empty in there.</li>
<li>So Ruby (happily) does nothing, because there is nothing to re-point foo to.</li>
</ol>
<p>That's the story. And this story tells me foo ends up nil.<br>
What's the new story about ruby 1.9 if it's not a bug?<br>
=end</p> Backport191 - Bug #2422: splat operator fails on array of 1 elementhttps://bugs.ruby-lang.org/issues/2422?journal_id=101062010-04-12T03:04:27Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Rejected</i></li></ul><p>=begin<br>
Hi,</p>
<blockquote>
<p>What's the new story about ruby 1.9 if it's not a bug?</p>
</blockquote>
<p>If rvalue has a single expression, it returns the value itself.<br>
If rvalue has multiple expressions (including splat), it returns<br>
an array whose elements are each result.</p>
<p>If lvalue has a single variable, it assigns rvalue itself.<br>
If lvalue has multiple variables, corresponding variable and<br>
rvalue element are assigned respectively (if rvalue is not an<br>
array, it is interpreted as singleton array).</p>
<p>Anyway, this is never a bug, It is contemplated, intended spec<br>
change. Please accept reality.</p>
<p>You can register the same change request to Feature tracker,<br>
but I strongly advise you to provide more concrete reason than<br>
intuition.</p>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p>