https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17097754782019-09-24T13:21:27ZRuby Issue Tracking SystemRuby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816862019-09-24T13:21:27ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-4 priority-default closed" href="/issues/15708">Bug #15708</a>: Implicit numbered argument decomposes an array</i> added</li></ul> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816882019-09-24T13:21:36ZEregon (Benoit Daloze)
<ul><li><strong>Related to</strong> <i><a class="issue tracker-5 status-7 priority-4 priority-default closed" href="/issues/15723">Misc #15723</a>: Reconsider numbered parameters</i> added</li></ul> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816892019-09-24T13:23:07ZEregon (Benoit Daloze)
<ul></ul><p>Of course, having <code>_</code> as the only unnamed parameter would have <code>|x|</code> semantics,<br>
but I guess it's too late for that and now we have <code>_<n></code> parameters.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816902019-09-24T13:25:13ZEregon (Benoit Daloze)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/81690/diff?detail_id=55131">diff</a>)</li></ul> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816912019-09-24T13:29:02Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Assignee</strong> changed from <i>Eregon (Benoit Daloze)</i> to <i>matz (Yukihiro Matsumoto)</i></li></ul><p>When <code>_1</code> is same as <code>|x|</code>, what does <code>[[1, 2]].map {_1 + _2}</code> mean?<br>
The meaning of <code>_1</code> changes if <code>_2</code> is used or not?</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816922019-09-24T13:37:29ZEregon (Benoit Daloze)
<ul></ul><p>nobu (Nobuyoshi Nakada) wrote:</p>
<blockquote>
<p>When <code>_1</code> is same as <code>|x|</code>, what does <code>[[1, 2]].map {_1 + _2}</code> mean?</p>
</blockquote>
<p>It means <code>[[1, 2]].map { |a,b| a + b } # => [3]</code> of course.</p>
<blockquote>
<p>The meaning of <code>_1</code> changes if <code>_2</code> is used or not?</p>
</blockquote>
<p>Yes, just like <code>Proc#arity</code> changes.</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="o">-></span> <span class="p">{</span> <span class="n">_1</span> <span class="p">}.</span><span class="nf">arity</span> <span class="c1">#=> 1</span>
<span class="o">-></span> <span class="p">{</span> <span class="n">_2</span><span class="p">;</span> <span class="n">_1</span> <span class="p">}.</span><span class="nf">arity</span> <span class="c1">#=> 2</span>
</code></pre>
<p>It's just consistent.<br>
We have to accept the drawback that numbered parameters change arity, there is no way around that.</p>
<p>Changing arity with named parameters has the same effect (<code>[[1, 2]].map { |a| a }</code> to <code>[[1, 2]].map { |a,b| a }</code>).</p>
<p>My main point is we want <code>_1</code> to be the non-dangerous behavior.</p>
<p>Changing arity can break things, that is not new, but indeed using numbered parameters makes the change less obvious in the source. That is intrinsically a drawback of numbered parameters (i.e., of not having an explicit list of parameters in one place).</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816932019-09-24T13:53:32Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>Some counter-points (that being said, I dislike the "unnamed parameters" idea as a whole, because I am afraid this feature -- being just "shorter" while staying imperative -- will stay in the way of adoption of more promising features like <code>&obj.:method</code>, experiments towards proper currying etc.):</p>
<p><strong>First</strong></p>
<blockquote>
<p><code>|x,|</code> is almost never used in Ruby, and for good reasons</p>
</blockquote>
<p>Honestly, we use it pretty frequently in our codebase and find it appealing. It is the shortest and pretty clear (YMMV, of course) way of processing only first elemente of "tuple-alike" arrays, like zips of data or data with indexes. Like, "find indexes of paragraphs matching some criteria":</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">paragraphs</span><span class="p">.</span><span class="nf">each_with_index</span><span class="p">.</span><span class="nf">select</span> <span class="p">{</span> <span class="o">|</span><span class="n">para</span><span class="p">,</span><span class="o">|</span> <span class="n">para</span><span class="p">.</span><span class="nf">match?</span><span class="p">(</span><span class="o">....</span><span class="p">)</span> <span class="p">].</span><span class="nf">map</span><span class="p">(</span><span class="o">&</span><span class="ss">:last</span><span class="p">)</span>
</code></pre>
<p>Of course, here we can dive into bike-shedding about "real Jedi will write <code>{ |para, _idx|</code>, because it is easier to ....", but I believe "some people use it" is enough counter-argument to "nobody uses it" :)</p>
<p><strong>Second</strong>, we have "0 is whole, 1 is first match, etc." conditions in other places of Ruby—string matching:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">m</span> <span class="o">=</span> <span class="s2">"Serhii Zhadan"</span><span class="p">.</span><span class="nf">match</span><span class="p">(</span><span class="sr">/^(.+?) (.+?)$/</span><span class="p">)</span>
<span class="c1"># => #<MatchData "Serhii Zhadan" 1:"Serhii" 2:"Zhadan"></span>
<span class="n">m</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span>
<span class="c1"># => "Serhii Zhadan"</span>
<span class="n">m</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span>
<span class="c1"># => "Serhii" </span>
</code></pre>
<p><strong>Third</strong>, I believe that in most of real, non-artificial situations, processing of sequence of heterogenous (some unpackable, some not) values with "shortcut blocks args" is a situation to either avoid, or being aware of your data nature. And with homogenous data, the problem is non-existent, while benefits are pretty obvious:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="o"><<-</span><span class="no">GRADES</span><span class="sh">
John:4
Mary:5
Paul:3
Vasily:2
</span><span class="no">GRADES</span>
<span class="p">.</span><span class="nf">lines</span><span class="p">(</span><span class="ss">chomp: </span><span class="kp">true</span><span class="p">)</span>
<span class="p">.</span><span class="nf">map</span> <span class="p">{</span> <span class="n">_0</span><span class="p">.</span><span class="nf">split</span><span class="p">(</span><span class="s1">':'</span><span class="p">)</span> <span class="p">}</span>
<span class="p">.</span><span class="nf">to_h</span> <span class="p">{</span> <span class="p">[</span><span class="n">_1</span><span class="p">,</span> <span class="n">_2</span><span class="p">.</span><span class="nf">to_i</span><span class="p">]</span> <span class="p">}</span>
</code></pre>
<p>In your proposal, the last line should be, like</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="n">to_h</span> <span class="p">{</span> <span class="p">[</span><span class="n">_1</span><span class="p">[</span><span class="mi">0</span><span class="p">],</span> <span class="n">_1</span><span class="p">[</span><span class="mi">1</span><span class="p">].</span><span class="nf">to_i</span><span class="p">]</span> <span class="p">}</span>
<span class="c1"># or, OK, give up with them</span>
<span class="n">to_h</span> <span class="p">{</span> <span class="o">|</span><span class="n">n</span><span class="p">,</span> <span class="n">g</span><span class="o">|</span> <span class="p">[</span><span class="n">n</span><span class="p">,</span> <span class="n">g</span><span class="p">.</span><span class="nf">to_i</span><span class="p">]</span> <span class="p">}</span>
</code></pre>
<p>I believe examples like mine, like "quick-and-somewhat dirty" experiments is exactly the target code to be simplified by the numbered parameters,</p>
<p><strong>UPD:</strong> OK, the last point is answered while I've writing this :)</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816952019-09-24T16:04:26Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>Hmmm. I find underscores to be harder to read in combination with<br>
other parts (e. g. _abc or _123) whereas I use _ quite a bit in my<br>
own code.</p>
<p>I still like @1 @2 @3 etc... - however had, I have to admit that if<br>
the suggestion is to use _1 _2 _3 then I actually would rather prefer<br>
to not add this altogether. ;-)</p>
<p>I think the whole numbered parameters, while I like it in general,<br>
created some problems for people to adjust their mindset into. On<br>
the other hand, since ruby users are not forced to use it, they can<br>
ignore it, which happens with other features too.</p>
<p>zverok wrote:</p>
<blockquote>
<p>Some counter-points (that being said, I dislike the "unnamed parameters"<br>
idea as a whole</p>
</blockquote>
<p>I begin to dislike it mostly due to different syntax use. ;-)</p>
<p>However had, perhaps there should be another discussion at some upcoming<br>
dev meeting. Perhaps not necessarily meant to stop the addition as such,<br>
but to consider it for later addition (or more discussion). Also what<br>
zverok wrote:</p>
<blockquote>
<p>because I am afraid this feature -- being just "shorter" while staying<br>
imperative</p>
</blockquote>
<p>I am not sure what you mean with "imperative" here, but ok.</p>
<blockquote>
<p>will stay in the way of adoption of more promising features like<br>
&obj.:method, experiments towards proper currying etc.):</p>
</blockquote>
<p>I would actually rpefer to not add EITHER numbered parameters and<br>
NEITHER your &obj.:method notation. This may be individual preference,<br>
of course, but I dislike that we may have to look too closely. I am<br>
not sure why you connect these two, though; to me both are totally<br>
independent. And even if numbered parameters are not added, I still<br>
would prefeer there be no &obj.:method notation altogether nor .:<br>
even though I can understand that it enables new possibilities in regards<br>
to writing ruby code. You write awesome code; but on the other hand,<br>
I find it very hard to read and understand.</p>
<p>IMO it may be best for ruby to stay simpler and reject most of these<br>
syntax changes. ;-)</p>
<blockquote>
<p>In your proposal, the last line should be, like</p>
</blockquote>
<pre><code>to_h { [_1[0], _1[1].to_i] }
</code></pre>
<p>I actually dislike this even more than the suggestion for "it". :D</p>
<p>Anyway, I do not want to distract too much, so perhaps there can be<br>
another dev meeting/discussion. Of course matz decides, but this<br>
becomes a bit difficult here if we inter-connect different features<br>
and proposals with one another; or different syntax. I am still in<br>
the pro-numbered parameters camp in general though, just not as close<br>
to the _numbers variants camp. Good syntax is difficult. :P</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=816992019-09-24T21:38:02ZDan0042 (Daniel DeLorme)
<ul></ul><p><code>proc{ |x,| }.arity</code> == 1, so <code>_1</code> is consistent with that.</p>
<p>In order to get the tuples' first value you would need to do <code>array_of_arrays.map{_2;_1}</code> because otherwise <code>_1</code> would mean the entire tuple.</p>
<p>This argument is really weird. Is it really so unsufferable to use <code>_0</code> instead of <code>_1</code>? Do you really think it would be <em>better</em> if the meaning of <code>_1</code> changed depending on whether <code>_2</code> is also used? Sorry, but I can't wrap my head around that one. The current syntax is clean and straightforward: use <code>_0</code> in general and use <code>_1</code>,<code>_2</code>,etc for dereferencing. Maybe <code>_</code> or <code>__</code> would have been better than <code>_0</code>, but that's what we've got.</p>
<blockquote>
<p>Try to convince me otherwise.<br>
If not, in one week I want to apply this change.</p>
</blockquote>
<p>Please don't ask people to convince you when it's obvious you've already made up your mind.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817002019-09-24T21:45:30ZEregon (Benoit Daloze)
<ul></ul><p>zverok (Victor Shepelev) wrote:</p>
<blockquote>
<p>Honestly, we use it pretty frequently in our codebase and find it appealing.<br>
It is the shortest and pretty clear (YMMV, of course) way of processing only first elemente of "tuple-alike" arrays, like zips of data or data with indexes.</p>
</blockquote>
<p>How frequently compared to just <code>|x|</code>? I would guess < 5% on any non-trivial codebase.<br>
But you are right, frequency of usage isn't so important.</p>
<p>I agree <code>|x,|</code> has its uses, and I think it's perfectly fine to use it when it's intentional.<br>
The explicit trailing comma shows the intention to drop remaining args.</p>
<p>But <code>_1</code> shouldn't mean "drop everything but the first element if the first parameter is an Array, otherwise return the first parameter".<br>
<code>_1</code> should mean "the first parameter" just like<br>
<code>_2</code> means "the second parameter" and<br>
<code>_3</code> means "the third parameter".</p>
<p>Would anyone contradict that? :p</p>
<blockquote>
<p><strong>Second</strong>, we have "0 is whole, 1 is first match, etc." conditions in other places of Ruby—string matching:</p>
</blockquote>
<p>Indeed, I didn't realize that symmetry.<br>
I don't think it's good to have two different ways with subtle differences to refer to the 1st parameter though.<br>
I believe <code>_1</code> must be simple to define and similar to <code>_2</code>.<br>
It's all very confusing if <code>_0</code> is the first parameter and <code>_2</code> is the second parameter, isn't it?</p>
<blockquote>
<p><strong>Third</strong>, I believe that in most of real, non-artificial situations, processing of sequence of heterogenous (some unpackable, some not) values with "shortcut blocks args" is a situation to either avoid, or being aware of your data nature.</p>
</blockquote>
<p>What about libraries, e.g., taking an Enumerable from the application and using <code>enum.map { transform(_1) }</code>?<br>
Do you think it's OK to have the library work if all elements are number but break horribly if all elements are arrays?<br>
There are certainly a lot of methods that must behave identically (and not drop elements) no matter the class of the parameter passed to it.</p>
<p>Yes, <code>_0</code> can be used to avoid that, but then it's clear <code>_0</code> semantics should be preferred in all cases but those were dropping elements is intentional.<br>
And then if it's intentional, we already have a great syntax showing it: <code>|x,|</code>.</p>
<p>So the syntax for the first, second, etc arguments should be consistent (i.e., <code>_1</code>, <code>_2</code>, <code>_3</code>), and by that <code>_1</code> must not decompose arrays and drop elements, but behave like <code>|x|</code>.<br>
Quod Erat Demonstrandum.</p>
<blockquote>
<p>In your proposal, the last line should be, like</p>
</blockquote>
<p>No, my proposal does not change the semantics of <code>{ [_1, _2.to_i] }</code>.<br>
That is always the same as <code>{ |a,b| [a, b.to_i] }</code>.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817022019-09-24T22:14:33ZEregon (Benoit Daloze)
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<p><code>proc{ |x,| }.arity</code> == 1, so <code>_1</code> is consistent with that.</p>
</blockquote>
<p>Which sounds like another bug to me, because that block happily accepts more arguments, and should be identical to <code>|x,*|</code>, which <code>proc {|x,*|}.arity # => -2</code>.</p>
<p>What is your point?<br>
My point about arity was that if you add an argument, arity changes, and behavior changes too.<br>
Everyone understands adding an extra argument to a block (or lambda) might change semantics (e.g., <code>[1,[2,3]].map(&-> { _1; _2 })</code> is ArgumentError), isn't it?<br>
That's already the case today with named parameters.</p>
<p>How do you argue that <code>_2</code> "takes the second parameter" but <code>_1</code> "extracts the first element of the first parameter"?<br>
How is that consistent?</p>
<blockquote>
<p>In order to get the tuples' first value you would need to do <code>array_of_arrays.map{_2;_1}</code> because otherwise <code>_1</code> would mean the entire tuple.</p>
</blockquote>
<p>You would need to do <code>array_of_arrays.map { |x,| x }</code>. The tiny extra verbosity is warranted for dropping elements.<br>
Try adding 1 to each element of a 2 dimensional array (a matrix).<br>
<code>_0</code> must be used currently, but really taking the element as it is (<code>|x|</code>) are the only correct semantics in general if you do not know the specific element types.<br>
Why would the correct semantics in general need a different syntax (<code>_0</code> and not <code>_1</code>)?</p>
<p>BTW, about typing, how would you type <code>enum.map { _1 }</code> with enum an <code>Enumerable[T]</code>?<br>
Isn't it impossible, because the behavior is inconsistent at runtime?</p>
<blockquote>
<p>This argument is really weird. Is it really so unsufferable to use <code>_0</code> instead of <code>_1</code>?</p>
</blockquote>
<p>Yes, it's inconsistent and I'm pretty sure people would use <code>_1</code> like <code>|x|</code>, without realizing it's just broken when it's passed an Array.<br>
Do we want frequent bugs based on this instead of just having to use <code>|x,|</code> when wanting to drop elements?</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817032019-09-24T22:18:59ZEregon (Benoit Daloze)
<ul></ul><p>Here is another inconsistency on current trunk:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="p">[</span><span class="mi">1</span><span class="p">,[</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]].</span><span class="nf">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">x</span><span class="o">|</span> <span class="n">x</span> <span class="p">}</span> <span class="c1"># => [1, [2, 3]]</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,[</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]].</span><span class="nf">map</span> <span class="p">{</span> <span class="o">|</span><span class="n">x</span><span class="p">,</span><span class="o">|</span> <span class="n">x</span> <span class="p">}</span> <span class="c1"># => [1, 2]</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,[</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]].</span><span class="nf">map</span> <span class="p">{</span> <span class="n">_1</span> <span class="p">}</span> <span class="c1"># => [1, 2]</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,[</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]].</span><span class="nf">map</span><span class="p">(</span><span class="o">&-></span> <span class="p">{</span> <span class="n">_1</span> <span class="p">})</span> <span class="c1"># => [1, [2, 3]]</span>
<span class="p">[</span><span class="mi">1</span><span class="p">,[</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">]].</span><span class="nf">map</span><span class="p">(</span><span class="o">&-></span> <span class="n">x</span> <span class="p">{</span> <span class="n">x</span> <span class="p">})</span> <span class="c1"># => [1, [2, 3]]</span>
</code></pre>
<p>So <code>_1</code> in lambdas is <code>|x|</code>, but it's <code>|x,|</code> in procs?</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817042019-09-24T22:39:42ZEregon (Benoit Daloze)
<ul></ul><p>It's all about definitions. How do we explain numbered parameters?</p>
<p>Isn't <code>_1</code> the first parameter, as in <code>x</code> in <code>{ |x| }</code> and <code>x</code> in <code>{ |x,y| }</code>?<br>
And therefore <code>_2</code> the second parameter as in <code>y</code> in <code>{ |x,y| }</code>?</p>
<p>Of course, <code>{ |x| x }</code> and <code>{ |x,y| x }</code> already have different semantics, so why should <code>{ _2; _1 }</code> not be different than <code>{ _1 }</code> ?</p>
<p>I think that makes a lot of sense, is intuitive, and is very easy to explain.</p>
<p>But the current semantics don't match that.<br>
How would we define the current semantics, without being very complex or confusing?</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817062019-09-25T03:27:33Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a> <a href="/issues/16178">[ruby-core:95070]</a> beats me. I am persuaded. I agree with:</p>
<ul>
<li>
<code>_1</code> (and no other numbered parameters) to work as <code>|x|</code>.</li>
<li>giving up <code>_0</code>.</li>
</ul>
<p>Matz.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817072019-09-25T04:02:49Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset <a class="changeset" title="Changed numbered parameters semantics * `_1` (and no other numbered parameters) to work as `|x|`..." href="https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/55e1e22b2d44a8a1eca0f6ed2b11dc0f564f7192">git|55e1e22b2d44a8a1eca0f6ed2b11dc0f564f7192</a>.</p>
<hr>
<p>Changed numbered parameters semantics</p>
<ul>
<li>
<code>_1</code> (and no other numbered parameters) to work as <code>|x|</code>.</li>
<li>giving up <code>_0</code>.</li>
</ul>
<p><a href="/issues/16178">[ruby-core:95074]</a> [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Numbered parameters: _1 should be the same as |x| and _0 should not exist (Closed)" href="https://bugs.ruby-lang.org/issues/16178">#16178</a>]</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817122019-09-25T10:15:50ZDan0042 (Daniel DeLorme)
<ul></ul><blockquote>
<p>How would we define the current semantics, without being very complex or confusing?</p>
</blockquote>
<p>Beautifully simple:<br>
_0 is a single implicit parameter, as in x in { |x| }<br>
_1 is the first numbered parameter, as in x in { |x,y,z,etc| }<br>
_2 is the second numbered parameter, as in y in { |x,y,z,etc| }</p>
<p>How unfortunate that you managed to persuade matz :-(</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817132019-09-25T10:44:07Zsawa (Tsuyoshi Sawada)
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<p>How unfortunate that you managed to persuade matz :-(</p>
</blockquote>
<p>Completely agreed.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817142019-09-25T11:16:44Zdecuplet (Nikita Shilnikov)fg@flashgordon.ru
<ul></ul><p>Just to make it more polarized, I like the change, it feels more natural.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817172019-09-25T11:54:49Zko1 (Koichi Sasada)
<ul></ul><blockquote>
<p>Beautifully simple:<br>
_0 is a single implicit parameter, as in x in { |x| }<br>
_1 is the first numbered parameter, as in x in { |x,y,z,etc| }<br>
_2 is the second numbered parameter, as in y in { |x,y,z,etc| }</p>
</blockquote>
<p>I think <code>_0</code> and <code>_1</code> are very confusing because people can consider it is sequential meaning. However, the meaning is different.</p>
<p>It is same as <code>$0</code> and <code>$1</code>, but they are completely different feature (program name and regexp). <code>_0</code> and <code>_1</code> is very confusing.</p>
<p>This proposal also introduces inconsistency, but it is better than <code>_0</code> and <code>_1</code> idea, I think.</p>
<blockquote>
<p>Of course, having _ as the only unnamed parameter would have |x| semantics,<br>
but I guess it's too late for that and now we have _ parameters.</p>
</blockquote>
<p>Completely agreed (and I like <code><></code> for <code>|e|</code> and <code><n></code> for <code>_n</code> :p, but rejected this notation).</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817182019-09-25T12:39:47ZDan0042 (Daniel DeLorme)
<ul></ul><blockquote>
<p>I think <code>_0</code> and <code>_1</code> are very confusing because people can consider it is sequential meaning. However, the meaning is different.</p>
</blockquote>
<p>I agree, but matz chose _0 for the implicit parameter. I think it's a mistake to then use that naming to change the semantics of implicit vs numbered parameters. The reasoning is backwards.</p>
<blockquote>
<p>Completely agreed (and I like <code><></code> for <code>|e|</code> and <code><n></code> for <code>_n</code> :p, but rejected this notation).</p>
</blockquote>
<p>Or <code>__</code> for <code>|e|</code> and <code>_n_</code> for <code>|e,*|</code> ... this is all a bikeshed anyway :D</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817192019-09-25T16:12:10ZEregon (Benoit Daloze)
<ul></ul><p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<blockquote>
<p>How would we define the current semantics, without being very complex or confusing?</p>
</blockquote>
<p>Beautifully simple:<br>
_0 is a single implicit parameter, as in x in { |x| }<br>
_1 is the first numbered parameter, as in x in { |x,y,z,etc| }</p>
</blockquote>
<p>That's incomplete, it's much more tricky than that in the now previous semantics:<br>
<code>_1</code> is the first numbered parameter, as in <code>x</code> in <code>{ |x,y,z,etc| }</code> if there are at least 2 numbered parameters or the first parameter's runtime value is not an Array, otherwise extracts the first argument of the first parameter.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817202019-09-25T16:13:34ZEregon (Benoit Daloze)
<ul></ul><p>matz (Yukihiro Matsumoto) wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/772">@Eregon (Benoit Daloze)</a> <a href="/issues/16178">[ruby-core:95070]</a> beats me. I am persuaded. I agree with:</p>
<ul>
<li>
<code>_1</code> (and no other numbered parameters) to work as <code>|x|</code>.</li>
<li>giving up <code>_0</code>.</li>
</ul>
</blockquote>
<p>Thank you for your decision.<br>
I think this is going to save many bugs and make numbered parameters significantly simpler.</p> Ruby master - Bug #16178: Numbered parameters: _1 should be the same as |x| and _0 should not existhttps://bugs.ruby-lang.org/issues/16178?journal_id=817502019-09-26T17:30:53Zalanwu (Alan Wu)
<ul></ul><p>Eregon (Benoit Daloze) wrote:</p>
<blockquote>
<p>Dan0042 (Daniel DeLorme) wrote:</p>
<blockquote>
<blockquote>
<p>How would we define the current semantics, without being very complex or confusing?</p>
</blockquote>
<p>Beautifully simple:<br>
_0 is a single implicit parameter, as in x in { |x| }<br>
_1 is the first numbered parameter, as in x in { |x,y,z,etc| }</p>
</blockquote>
<p>That's incomplete, it's much more tricky than that in the now previous semantics:<br>
<code>_1</code> is the first numbered parameter, as in <code>x</code> in <code>{ |x,y,z,etc| }</code> if there are at least 2 numbered parameters or the first parameter's runtime value is not an Array, otherwise extracts the first argument of the first parameter.</p>
</blockquote>
<p>That's still incomplete, since it doesn't explain why <code>_1</code> doesn't decompose when used in lambdas. If it always decomposes, it'd be more self consistent.<br>
Anyways, I like the new rule better, since it has less corner cases.</p>