https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112020-04-30T12:07:54ZRuby Issue Tracking SystemRuby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=853302020-04-30T12:07:54Zsawa (Tsuyoshi Sawada)
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/85330/diff?detail_id=56949">diff</a>)</li></ul> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=853322020-04-30T19:42:43Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>I do not have a strong preference here either way; I guess one can reason in<br>
favour for both behaviour types/styles, and I think a primary point in the<br>
suggestion is that it refers to startless/endless situations, such as "5..",<br>
which I don't use myself, but one slight concern is this one:</p>
<pre><code>a[-1..-2] # => []
a[-10..-9] # => nil
</code></pre>
<p>Is this certain to not break a lot of code? I have not checked myself and I<br>
rarely use #slice anyway, but I do use a lot of [] in general. It's one of<br>
my favourite method calls in general, in ruby. :)</p>
<p>Admittedly I actually don't remember off-hand having ever used two negative<br>
indices here ... for some reason, I seem to use 0 or positive numbers a lot<br>
more.</p>
<p>No idea how/if other ruby users use or rely on that behaviour though but I<br>
think it would be important to get some specific overview about any potential<br>
effect (or side-effect) of proposed changes, even if the reasoning given is<br>
ok.</p> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=853732020-05-04T03:01:08ZDan0042 (Daniel DeLorme)
<ul></ul><p>Slicing returns nil when the index is out of bounds, and that can be a useful signal that something is wrong and we should fail fast. Having that nil return value provides information that is not present if it's auto-converted to an empty array, and it's easy to disregard that information by using <code>.to_a</code></p>
<p><code>arr[1..]</code><br>
Takes all items after the first one, but if there's no first item it can be argued this is an invalid input and returning nil is safer (fail fast) than pretending everything is as expected.</p>
<p><code>arr[-5..-1]</code><br>
Takes the last 5 items but if the array has less than 5 items it's an invalid input and we return nil (unlike <code>arr.last(5)</code>). If this proposal is accepted I'm not sure that returning an empty array makes sense here.</p>
<p>Now, all that being said... personally I don't remember ever having depended on array slicing returning a nil for out-of-bounds checking, but I <em>do</em> remember adding a bunch of <code>.to_a</code> or <code>&.each</code> to my code to account for this case. So I am tentatively positive about the idea. But caution is required.</p> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=853742020-05-04T06:34:12Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/85374/diff?detail_id=56967">diff</a>)</li></ul> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=853822020-05-05T20:23:39Zmarcandre (Marc-Andre Lafortune)marcandre-ruby-core@marc-andre.ca
<ul></ul><p>I'm strongly against this, for compatibility reasons and because current choice is a consistent convention.</p>
<p>Before proposing any incompatible change, especially for an API that is very much in use, please provide a compelling use case. If you write <code>ary[1..].reduce { }</code>, you must give a context (what contains <code>ary</code>, why would you want to skip the first value, why not use <code>values_at(1..)</code>, etc.).</p> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=856082020-05-14T04:52:31Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>I don't think the benefit of changing outweighs the pain of incompatibility. Rejected.</p>
<p>Matz.</p> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=856172020-05-14T09:32:29Zmrkn (Kenta Murata)muraken@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul> Ruby master - Feature #16822: Array slicing: nils and edge caseshttps://bugs.ruby-lang.org/issues/16822?journal_id=974042022-04-22T18:14:39Zjeremyevans0 (Jeremy Evans)merch-redmine@jeremyevans.net
<ul><li><strong>Has duplicate</strong> <i><a class="issue tracker-1 status-6 priority-4 priority-default closed" href="/issues/18741">Bug #18741</a>: Slicing an Array using index out of range inconsistent return type</i> added</li></ul>