<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 26, 2016 at 2:01 AM, Daniel Duan <span dir="ltr">&lt;<a href="mailto:daniel@duan.org" target="_blank">daniel@duan.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Jul 25, 2016, at 11:32 PM, David Hart via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="auto"><div><br></div><div><br>On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">   surface area and leverages the user&#39;s understanding of how ranges<br>
   work.<br>
<br>
   It also implies we can replace<br>
<br>
     x.removingPrefix(n)<br>
     x.removingSuffix(n)<br>
<br>
   with<br>
<br>
     x[$+n..&lt;]<br>
     x[..&lt;$-n]<br>
<br>
  for Collections.<br></blockquote><div><br></div><div>I&#39;m not enamored of this suggestion. It succeeds in reducing API surface area, but at a severe cost to readability. You&#39;d replace an unambiguous phrase (removing prefix or suffix), the meaning of which is further clarified by the consistent usage proposed in SE-0132, with a wordless spelling using some combination of [$+.&lt;]. Cognitively, also, it substantially increases the burden for the reader: it replaces a single argument with a nested series of arguments; first, one must understand the meaning of the $ placeholder, then one must consider an addition or subtraction operation, then the formation of a range, and in the last example, the use of that range as a subscript argument--again, all wordlessly. Finally, subscripts have so far not been &quot;forgiving,&quot; while today&#39;s `dropLast` very much is; this suggestion would add inconsistency by using a subscript for a forgiving or &quot;lenient&quot; operation.</div></div></blockquote><br><div>I second Xiaodi. I am against the slicing subscripts and the ones above look even more unreadable and inscrutable than those in the proposal. I don&#39;t understand the rational.</div></div></div></blockquote><div><br></div></div></div>The inspiration is D: <a href="https://dlang.org/d-array-article.html" target="_blank">https://dlang.org/d-array-article.html</a></div></div></blockquote><div><br></div><div>Neat. However, $+n and $-n remain problematic for me, one additional reason being that these suggest indices move themselves, which they no longer do in Swift 3. Of course, we could (and, in fact, we would have to) say that $+n is short for `x.index(x.startIndex, offsetBy: n)`, but that&#39;d be a pretty big contortion for the + operator.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></span></div></blockquote></div><br></div></div>