https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-01-14T07:21:39ZRuby Issue Tracking SystemRuby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=838422020-01-14T07:21:39Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>The background of this proposal: <a href="https://bugs.ruby-lang.org/issues/14183#note-101" class="external">https://bugs.ruby-lang.org/issues/14183#note-101</a></p>
<p>My personal feeling is the same as Jeremy; I'm negative because allowing the automatic Hash conversion makes the semantics complicated. However, the argument semantics of non-lambda Proc are already a mess :-) So it might be possible, though I don't like it.</p>
<p>However, we need to confirm if there are so many real-world use cases that rely on the old behavior. Currently, we have only one practical case found in rubocop in the discussion above, which has been already fixed (thanks to <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/9869">@koic (Koichi ITO)</a>!). IMO, it is far from enough to change it.</p> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=838442020-01-14T07:45:42Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><blockquote>
<p>I'm negative because allowing the automatic Hash conversion makes the semantics complicated. However, the argument semantics of non-lambda Proc are already a mess :-) So it might be possible, though I don't like it.</p>
</blockquote>
<p>I don't think it is a "mess". I think it is the "right" kind of complication to make code more easy to write. As I've already written elsewhere, there is a non-neglectable gap between what is "consistent" for computers, and what is "consistent" for humans.</p>
<blockquote>
<p>However, we need to confirm if there are so many real-world use cases that rely on the old behavior.</p>
</blockquote>
<p>My proposal, in its essence, is not "please preserve the 'old' behavior, because otherwise, it would break something".</p>
<p>It is "please see this behavior as a modern and consistent way to use Ruby, which should not be broken by argument separation". Not something that "well, generally, not recommended, but you <em>can</em> do it", but as something that is seen as a "good and pretty thing, that should be promoted and used more".</p>
<p>I believe I am showcasing enough of the usability of the "unpacking" approach in the ticket itself (and it is not artificially constructed, just abstracted a bit example from the real-world app). I see two ways it can be refuted:</p>
<ol>
<li>Show <em>equally clean and powerful</em> way of doing things (which, I believe, is not possible, hence the ticket)</li>
<li>Say "it doesn't matter"/"doesn't look better"/"just rewrite it with separate methods", which will be the end of the discussion :)</li>
</ol> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=838522020-01-14T10:29:47Zmame (Yusuke Endoh)mame@ruby-lang.org
<ul></ul><p>I remember. I talked about the issue with matz before 2.7 release, and he said it does not matter. He may have changed his mind, so I'll confirm him at the next meeting.</p>
<p>In my personal opinion, it matters if there are already many real-world use cases. Otherwise, it does not matter. I guess matz has the same feelings. My current observation is that such a code is not so often written.</p> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=838922020-01-16T04:36:13ZDan0042 (Daniel DeLorme)
<ul></ul><p>My alternative proposal to accomplish the same objective: <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Staged warnings and better compatibility for keyword arguments in 2.7.1 (Open)" href="https://bugs.ruby-lang.org/issues/16511">#16511</a></p> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=838982020-01-16T05:31:53Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>I admit the recent change disables something once we theoretically could. But there's no big usage for this particular feature and it doesn't worth adding even more complexity.</p>
<p>Matz.</p> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=850722020-04-12T09:45:41Zinopinatus (Joshua GOODALL)
<ul></ul><p>I am another person with blocks affected in a production application codebase, found sixteen uses.</p>
<p>I see a cluster of people reporting an issue. Are we the tip of an iceberg, or the entire iceberg? There is a school of programmer that loves list comprehensions and uses them often and expressively. It may not be as theoretical an issue as hoped. The examples at <a href="https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/" class="external">https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/</a> are about methods with keyword args, there is no guidance for blocks with keyword arguments.</p>
<p>So I have monkey-patched Enumerable to give me explicit splatting:</p>
<pre><code class="ruby syntaxhl" data-language="ruby"><span class="k">module</span> <span class="nn">Enumerable</span>
<span class="k">def</span> <span class="nf">splat</span>
<span class="n">each</span> <span class="p">{</span> <span class="o">|</span><span class="n">args</span><span class="o">|</span> <span class="k">yield</span> <span class="o">**</span><span class="n">args</span> <span class="p">}</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre>
<p>Now I can write <code>array_of_hashes.map.splat { |this:, that:, other: other_default, **rest| ... }</code> without warnings. Also works with each, select and so on.</p>
<p>All the alternatives seemed quite ugly and bad for programmer happiness.</p> Ruby master - Feature #16494: Allow hash unpacking in non-lambda Prochttps://bugs.ruby-lang.org/issues/16494?journal_id=850742020-04-12T10:26:33Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>Honestly, after how Matz has stated his opinion, I don't expect there is any room for dialogue.</p>
<p>The only thing I'd like to add is I feel a huge discrepancy in this decision, in my head it happens this way:</p>
<ol>
<li>On the one hand, a lot of work is done to make keyword arguments "real" (and therefore more useful, less confusing, and ultimately more widely used)</li>
<li>But at the same time, changes accidentally prohibit one of the styles that is <em>beneficial</em> for keyword arguments acceptance, short, clear and <em>irreplaceable</em>. The point that <em>currently</em> the style is known lesser than it deserves for me feels inferior to the point that <em>potentially</em> it can be one of "Ruby's keyword arguments" selling points.</li>
</ol>
<p>In other words, this decision changes the <em>future</em> of some concepts arguing that they were not that popular in the <em>past</em>. I find it quite sad.</p>