<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 25, 2016, at 11:32 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class=""><br class="">On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> surface area and leverages the user's understanding of how ranges<br class="">
work.<br class="">
<br class="">
It also implies we can replace<br class="">
<br class="">
x.removingPrefix(n)<br class="">
x.removingSuffix(n)<br class="">
<br class="">
with<br class="">
<br class="">
x[$+n..<]<br class="">
x[..<$-n]<br class="">
<br class="">
for Collections.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm not enamored of this suggestion. It succeeds in reducing API surface area, but at a severe cost to readability. You'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 [$+.<]. 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 "forgiving," while today's `dropLast` very much is; this suggestion would add inconsistency by using a subscript for a forgiving or "lenient" operation.</div></div></blockquote><br class=""><div class="">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't understand the rational.</div></div></div></blockquote><div><br class=""></div>The inspiration is D: <a href="https://dlang.org/d-array-article.html" class="">https://dlang.org/d-array-article.html</a></div><div><br class=""><blockquote type="cite" class=""><div class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>