<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">There’s two different issues here, as far as I can tell. (both of which the $ operator seems to be trying to solve) The first is being able to use the start and end indices of a collection in a more concise way, so you can write <span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">[$3..<$]</span> instead of <span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">[(</span><span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">.</span><span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">startIndex</span><span style="font-family: Menlo; font-size: 11px;" class="">+</span><span style="font-family: Menlo; font-size: 11px; color: rgb(49, 44, 221);" class="">3</span><span style="font-family: Menlo; font-size: 11px;" class="">)..<</span><span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">.</span><span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">endIndex]</span>, and the second is coercing <span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">Int</span>s into the indices of other collections, possibly in worse-than-O(1) time.</div><div class=""><br class=""></div><div class="">With regards to arrays, all of these operations are going to be O(1), of course. So, in that case, there’s no need to steer people away from using the offset version. To me, something like <span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">[</span><span style="font-family: Menlo; font-size: 11px; color: rgb(49, 44, 221);" class="">3</span><span style="font-family: Menlo; font-size: 11px;" class="">..<</span><span style="font-family: Menlo; font-size: 11px;" class="">]</span> is clear, and it’s obvious what’s going on. If the end index is left out, it’s kind of “implicit”. Similarly with the start index: I’d expect <span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">[..<</span><span style="font-family: Menlo; font-size: 11px; color: rgb(49, 44, 221);" class="">3</span><span style="font-family: Menlo; font-size: 11px;" class="">]</span> to return the first three elements of the array.</div><div class=""><br class=""></div><div class="">If you’re to follow that logic through, and use the same language with array slices, I think that “offset-as-default” is the only way that makes sense. Of course, access to the indices of the original array are important, but you can manage that with a labelled subscript.</div><div class=""><br class=""></div><div class="">In terms of non random-access collections, the open-ended and open-started slice syntax (<span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">ar</span><span style="font-family: Menlo; font-size: 11px;" class="">[</span><span style="font-family: Menlo; font-size: 11px; color: rgb(49, 44, 221);" class="">3</span><span style="font-family: Menlo; font-size: 11px;" class="">..<</span><span style="font-family: Menlo; font-size: 11px;" class="">]</span>) is still applicable, without any performance hit (if you only allowed the collection’s native index type to be used). Beyond that, I’m not sure what the best option is.</div><div class=""><br class=""></div><div class="">Oisín</div><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Dec 2015, at 21:08, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">It was an intentional decision for Swift's indexes to not be based on offset indexing. In many cases (including indexing into strings) calculating index offsets is an O(N) operation. The design of Swift's indexes is such that you pay the cost when constructing an index, rather than when using the index, so that way you can pay the cost once and re-use that index many times (and similarly, if you index over the collection, you can save indexes and revisit them without any cost). Switching to offset indexing by default would throw away that cost and cause a lot of collection operations to accidentally be O(N) when they look like they're O(1) (which would in turn cause many O(N) algorithms to accidentally become O(N^2)).<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<div class=""> </div>
<div class="">On Tue, Dec 22, 2015, at 12:58 PM, Donnacha Oisín Kidney wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">I don’t think I am. Maybe I’m confused: the current suggestion is the addition of a $ operator (or labelled subscripts, or another operator) to signify “offset indexing”, yes? As in:<br class=""></div>
<div class=""> </div>
<div class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79, 129, 135);" class="">someCollection<span class="colour" style="">[$3] == </span>someCollection<span class="colour" style="">[</span>someCollection<span class="colour" style="">.startIndex.advancedBy(</span><span class="colour" style="color:rgb(49, 44, 221)">3</span><span class="colour" style="">)]</span><br class=""></div>
</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79, 129, 135);" class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class="">someCollection<span class="colour" style="">[$3..<$]</span><span class="colour" style=""></span><span class="colour" style="">==</span><span class="colour" style=""></span>someCollection<span class="colour" style="">[</span>someCollection<span class="colour" style="">.startIndex.advancedBy(</span><span class="colour" style="color:rgb(49, 44, 221)">3</span><span class="colour" style="">)..<</span>someCollection<span class="colour" style="">.endIndex]</span><br class=""></div>
</div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(79, 129, 135);" class=""> </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class="">I’m not arguing against preserving the indexing of the base array, I understand its benefits. I’m arguing that, instead of using an extra indicator (like $) to indicate offset indexing, with the default being non-offset, why not have the <i class="">offset</i> indexing be the default, requiring an extra indication (like the label <span class="font" style="font-family:Menlo"><span class="size" style="font-size:11px">direct</span></span>) for the non-offset. This would keep the benefits of non-offset indexing, because you’d still have access to it. <br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""> </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class="">Is <i class="">think</i> that’s part of this discussion, right? I could start another thread, if not.<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""> </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class="">Oisín<br class=""></div>
<div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">On 22 Dec 2015, at 20:06, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div class="">On Mon, Dec 21, 2015, at 08:28 PM, Donnacha Oisín Kidney wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">Why not make the “forgiving” version the default? I mean, the majority of python-style composable slicing would be happening on arrays and array slices, for which there’s no performance overhead, and the forgiving version would seam to suit the “safe-by-default” philosophy. I’ve seen mistakes like this:<br class=""></div>
<div class=""> </div>
<div class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;" class=""><span class="colour" style="color:rgb(187, 44, 162)">let</span> ar = [<span class="colour" style="color:rgb(49, 44, 221)">1</span>, <span class="colour" style="color:rgb(49, 44, 221)">2</span>, <span class="colour" style="color:rgb(49, 44, 221)">3</span>, <span class="colour" style="color:rgb(49, 44, 221)">4</span>, <span class="colour" style="color:rgb(49, 44, 221)">5</span>]<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;" class=""><span class="colour" style="color:rgb(187, 44, 162)">let</span> arSlice = ar[<span class="colour" style="color:rgb(49, 44, 221)">2</span>..<<span class="colour" style="color:rgb(49, 44, 221)">5</span>]<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;" class="">arSlice[<span class="colour" style="color:rgb(49, 44, 221)">1</span>]<br class=""></div>
</div>
<div class=""> </div>
<div class="">on a few occasions, for instance. I would think something like this:<br class=""></div>
<div class=""> </div>
<div class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-size:11px;line-height:normal;font-family:Menlo;" class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""><span class="colour" style="color:rgb(187, 44, 162)">let</span> ar = [<span class="colour" style="color:rgb(49, 44, 221)">0</span>, <span class="colour" style="color:rgb(49, 44, 221)">1</span>, <span class="colour" style="color:rgb(49, 44, 221)">2</span>, <span class="colour" style="color:rgb(49, 44, 221)">3</span>, <span class="colour" style="color:rgb(49, 44, 221)">4</span>, <span class="colour" style="color:rgb(49, 44, 221)">5</span>]<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;min-height:13px;" class=""> </div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""><span class="colour" style="color:rgb(187, 44, 162)">let</span> arSlice = <span class="colour" style="color:rgb(79, 129, 135)">ar</span>[<span class="colour" style="color:rgb(49, 44, 221)">2</span>...] <span class="colour" style="color:rgb(79, 143, 0)">// [3, 4, 5]</span><br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;color:rgb(79, 143, 0);" class=""><span class="colour" style="color:rgb(79, 129, 135)">arSlice</span><span style="" class="">[..<</span><span class="colour" style="color:rgb(49, 44, 221)">3</span><span style="" class="">] </span>// [2, 3, 4]<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;color:rgb(79, 143, 0);" class=""><span class="colour" style="color:rgb(79, 129, 135)">arSlice</span><span style="" class="">[...</span><span class="colour" style="color:rgb(49, 44, 221)">3</span><span style="" class="">] </span>// [2, 3, 4, 5]<br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""><span class="colour" style="color:rgb(79, 129, 135)">arSlice</span>[direct: <span class="colour" style="color:rgb(49, 44, 221)">2</span>] <span class="colour" style="color:rgb(79, 143, 0)">// 2</span><br class=""></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;color:rgb(79, 129, 135);" class="">arSlice<span style="" class="">[</span><span class="colour" style="color:rgb(49, 44, 221)">0</span><span style="" class="">] </span><span class="colour" style="color:rgb(79, 143, 0)">// 2</span><br class=""></div>
</div>
</div>
<div class=""> </div>
<div class="">Would be what was expected from most programmers learning Swift, while leaving the unforgiving option open to those who need it.<br class=""></div>
</blockquote><div class=""> </div>
<div class="">You seem to be arguing against the notion that array slices preserve the indexing of the base array, but that's not what's under discussion here.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 22 Dec 2015, at 03:29, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><blockquote type="cite" class=""><div class=""><div class=""> </div>
<div class="">On Dec 21, 2015, at 1:51 PM, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:<br class=""></div>
</div>
<div class=""> </div>
<div class=""><div class=""><div class="">On Mon, Dec 21, 2015, at 11:56 AM, Dave Abrahams wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2015, at 8:52 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div class="">On Fri, Dec 18, 2015, at 02:39 PM, Dave Abrahams via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""> </div>
<div class="">Yes, we already have facilities to do most of what Python can do here, but one major problem IMO is that the “language” of slicing is so non-uniform: we have [a..<b], dropFirst, dropLast, prefix, and suffix. Introducing “$” for this purpose could make it all hang together<span class="font" style="font-family:AvenirNext-Regular"> and also eliminate the “why does it have to be so hard to look at the 2nd character of a string?!” problem. That is, use the identifier “$” (yes, that’s an identifier in Swift) to denote the beginning-or-end of a collection. Thus,</span><br class=""></div>
<div class=""><div style="font-family:AvenirNext-Regular;" class=""> </div>
<div style="font-family:AvenirNext-Regular;" class=""><span class="font" style="font-family:Menlo"> c[c.startIndex.advancedBy(3)] =><span style="white-space:pre;" class=""></span>c[$+3] // Python: c[3]</span><br class=""></div>
<div style="font-family:AvenirNext-Regular;" class=""><div class=""><span class="font" style="font-family:Menlo"> c[c.endIndex.advancedBy(-3)] =><span style="white-space:pre;" class=""></span>c[$-3] // Python: c[-3]</span><br class=""></div>
<div class=""> </div>
<div class=""><span class="font" style="font-family:Menlo"> c.dropFirst(3) =></span><span class="font" style="font-family:Menlo"></span><span class="font" style="font-family:Menlo">c[$+3...] // Python: c[3:]</span><br class=""></div>
</div>
<div style="font-family:AvenirNext-Regular;" class=""><span class="font" style="font-family:Menlo"> c.dropLast(3) =><span style="white-space:pre;" class=""></span>c[..<$-3] // Python: c[:-3]</span><br class=""></div>
<div style="font-family:AvenirNext-Regular;" class=""><span class="font" style="font-family:Menlo"> c.prefix(3) =><span style="white-space:pre;" class=""></span>c[..<$+3] // Python: c[:3]</span><br class=""></div>
<div style="font-family:AvenirNext-Regular;" class=""><span class="font" style="font-family:Menlo"> c.suffix(3) => <span style="white-space:pre;" class=""></span>c[$-3...] // Python: c[-3:]</span><br class=""></div>
<div style="font-family:AvenirNext-Regular;" class=""> </div>
</div>
<div class=""><span class="font" style="font-family:AvenirNext-Regular">It even has the nice connotation that, “this might be a little more expen</span><span class="font" style="font-family:Menlo">$</span><span class="font" style="font-family:AvenirNext-Regular">ive than plain indexing” (which it might, for non-random-access collections). </span>I think the syntax is still a bit heavy, not least because of “..<“ and “...”, but the direction has potential. <br class=""></div>
<div class=""> </div>
<div class=""> I haven’t had the time to really experiment with a design like this; the community might be able to help by prototyping and using some alternatives. You can do all of this outside the standard library with extensions.<br class=""></div>
</blockquote><div class=""> </div>
<div class="">Interesting idea.<br class=""></div>
<div class=""> </div>
<div class="">One downside is it masks potentially O(N) operations (ForwardIndex.advancedBy()) behind the + operator, which is typically assumed to be an O(1) operation.<br class=""></div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">Yeah, but the “$” is sufficiently unusual that it doesn’t bother me too much.<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class=""><div class="">Alos, the $+3 syntax suggests that it requires there to be at least 3 elements in the sequence, but prefix()/suffix()/dropFirst/etc. all take maximum counts, so they operate on sequences of fewer elements.<br class=""></div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">For indexing, $+3 would make that requirement. For slicing, it wouldn’t. I’m not sure why you say something about the<span class=""></span><u class="">syntax</u><span class=""></span>suggests exceeding bounds would be an error.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">Because there's no precedent for + behaving like a saturating addition, not in Swift and not, to my knowledge, anywhere else either. The closest example that comes to mind is floating-point numbers eventually ending up at Infinity, but that's not really saturating addition, that's just a consequence of Infinity + anything == Infinity. Nor do I think we should be establishing precedent of using + for saturating addition, because that would be surprising to people.<br class=""></div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">To call this “saturating addition” is an…interesting…interpretation. I don’t view it that way at all. The “saturation,” if there is any, happens as part of subscripting. You don’t even know what the “saturation limit” is until you couple the range expression with the collection. <br class=""></div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">In my view, the addition is part of an EDSL that represents a notional position offset from the start or end, then the subscript operation forgivingly trims these offsets as needed.<br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class=""><div class="">Additionally, I don't think adding a $ to an array slice expression should result in a behavioral difference, e.g. array[3..<array.endIndex] and array[$+3..<$] should behave the same<br class=""></div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">I see your point, but don’t (necessarily) agree with you there. “$” here is used as an indicator of several of things, including not-necessarily-O(1) and forgiving slicing. We could introduce a label just to handle that:<br class=""></div>
<div class=""> </div>
<div class=""> array[forgivingAndNotO1: $+3..<$] <br class=""></div>
<div class=""> </div>
<div class="">but it doesn’t look like a win to me.<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class=""> </div>
<blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">There's also some confusion with using $ for both start and end. What if I say c[$..<$]? We'd have to infer from position that the first $ is the start and the second $ is the end, but then what about c[$+n..<$+m]? We can't treat the usage of + as meaning "from start" because the argument might be negative. And if we use the overall sign of the operation/argument together, then the expression `$+n` could mean from start or from end, which comes right back to the problem with Python syntax.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">There’s a problem with Python syntax? I’m guessing you mean that c[a:b] can have very different interpretations depending on whether a and b are positive or negative?<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">Exactly.<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class="">First of all, I should say: that doesn’t really bother me. The 99.9% use case for this operation uses literal constants for the offsets, and I haven’t heard of it causing confusion for Python programmers. That said, if we wanted to address it, we could easily require n and m above to be literals, rather than Ints (which incidentally guarantees it’s an O(1) operation). That has upsides and downsides of course.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">I don't think we should add this feature in any form if it only supports literals.<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">I think Jacob's idea has some promise though:<br class=""></div>
<div class=""> </div>
<div class="">c[c.startIndex.advancedBy(3)] => c[fromStart: 3]<br class=""></div>
<div class="">c[c.endIndex.advancedBy(-3)] => c[fromEnd: 3]<br class=""></div>
</div>
</blockquote><div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class="">But naming the slice operations is a little trickier. We could actually just go ahead and re-use the existing method names for those:<br class=""></div>
<div class=""> </div>
<div class="">c.dropFirst(3) => c[dropFirst: 3]<br class=""></div>
<div class="">c.dropLast(3) => c[dropLast: 3]<br class=""></div>
<div class="">c.prefix(3) => c[prefix: 3]<br class=""></div>
<div class="">c.suffix(3) => c[suffix: 3]<br class=""></div>
<div class=""> </div>
<div class="">That's not so compelling, since we already have the methods, but I suppose it makes sense if you want to try and make all slice-producing methods use subscript syntax (which I have mixed feelings about).<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">Once we get efficient in-place slice mutation (via slice addressors), it becomes a lot more compelling, IMO. But I still don’t find the naming terribly clear, and I don’t love that one needs to combine two subscript operations in order to drop the first and last element or take just elements 3..<5.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">You can always add more overloads, such as<br class=""></div>
<div class=""> </div>
<div class="">c[dropFirst: 3, dropLast: 5]<br class=""></div>
<div class=""> </div>
<div class="">but I admit that there's a bunch of combinations here that would need to be added.<br class=""></div>
<div class=""> </div>
</div>
</blockquote><div class=""> </div>
<div class="">My point is that we have an English language soup that doesn’t compose naturally. Slicing in Python is much more elegant and composes well. If we didn’t currently have 6 separate methods (7 including subscript for index-based slicing) for handling this, that need to be separately documented and understood, I wouldn’t be so eager to replace the words with an EDSL, but in this case IMO it is an overall simplification.<br class=""></div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class="">My concern over trying to make it easier to take elements 3..<5 is that incrementing indexes is verbose for a reason, and adding a feature that makes it really easy to index into any collection by using integers is a bad idea as it will hide O(N) operations behind code that looks like O(1). And hiding these operations makes it really easy to accidentally turn an O(N) algorithm into an O(N^2) algorithm.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">As I’ve said, I consider the presence of “$” to be enough of an indicator that something co$tly is happening, though I’m open to other ways of indicating it. I’m trying to strike a balance between “rigorous” and “easy to use,” here. Remember that Swift has to work in playgrounds and for beginning programmers, too. I am likewise unsatisfied with the (lack of) ease-of-use of String as well (e.g. for lexing and parsing tasks), and have made improving it a priority for Swift 3. I view fixing the slicing interface as part of that job.<br class=""></div>
<div class=""> </div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">Even if we need separate symbols for “start” and “end” (e.g. using “$” for both might just be too confusing for people in the end, even if it works otherwise), I still think a generalized form that allows ranges to be used everywhere for slicing is going to be much easier to understand than this hodgepodge of words we use today.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">I'm tempted to say that if we do this, we should use two different sigils, and more importantly we should not use + and - but instead use methods on the sigils like advancedBy(), as if the sigils were literally placeholders for the start/end index. That way we won't write code that looks O(1) when it's not. For example:<br class=""></div>
<div class=""> </div>
<div class="">col[^.advancedBy(3)..<$]<br class=""></div>
<div class=""> </div>
<div class="">Although we'd need to revisit the names a little, because $.advancedBy(-3) is a bit odd when we know that $ can't ever take a non-negative number for that.<br class=""></div>
<div class=""> </div>
<div class="">Or maybe we should just use $ instead as a token that means "the collection being indexed", so you'd actually say something like<br class=""></div>
<div class=""> </div>
<div class="">col[$.startIndex.advancedBy(3)..<$.startIndex.advancedBy(5)]<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">I really like that direction, but I don’t think it does enough to solve the ease-of-use problem; I still think the result looks and feels horrible compared to Python for the constituencies mentioned above. <br class=""></div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">I briefly implemented this syntax, that was intended to suggest repeated incrementation:<br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class=""> </div>
<div class=""><div class=""><span class="font" style="font-family:Menlo"><span style="white-space:pre;" class=""></span>col.startIndex++3 // </span><span class="font" style="font-family:Menlo">col.startIndex.advancedBy(3)</span><br class=""></div>
</div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">I don’t think that is viable, especially now that we’ve dropped “++” and “--“. But this syntax <br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class=""><div class=""><div class=""><span class="font" style="font-family:Menlo"><span style="white-space:pre;" class=""></span>col[$.start</span><span class="font" style="font-family:Menlo">⛄️</span><span class="font" style="font-family:Menlo">3..<$.start⛄️5]</span><br class=""></div>
<div class=""> </div>
</div>
</div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">begins to be interesting for some definition of <span class="font" style="font-family:Menlo">⛄️</span>.<br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><blockquote type="cite" class=""><div class=""><div class="">This solves the problem of subscripting a collection without having to store it in a local variable, without discarding any of the intentional index overhead. Of course, if the goal is to make index operations more concise this doesn't really help much, but my argument here is that it's hard to cut down on the verbosity without hiding O(N) operations.<br class=""></div>
</div>
</blockquote><div class=""> </div>
<div class="">That ship has already sailed somewhat, because e.g. every Collection has to have a count property, which can be O(N). But I still like to uphold it where possible. I just don’t think the combination of “+” and “$” necessarily has such a strong O(1) connotation… especially because the precedent for seeing those symbols together is regexps.<br class=""></div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class=""> </div>
<blockquote type="cite" class=""><div class=""><div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">But the [fromStart:] and [fromEnd:] subscripts seem useful.<br class=""></div>
</div>
</blockquote><div class="">Yeah… I really want a unified solution that covers slicing as well as offset indexing.<br class=""></div>
<div class=""> </div>
</div>
<div class=""><div class="">-Dave<br class=""></div>
<div class=""> </div>
</div>
</blockquote><div class=""> </div>
</div>
</blockquote></div>
<div class=""> </div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class=""><div class="">-Dave<br class=""></div>
<div class=""> </div>
<div class=""> </div>
</div>
<div class=""> </div>
<div class=""><img src="https://www.fastmailusercontent.com/proxy/160d94e31509603969b312614f1fe37c008fe3c9b409e406c9f929df417ea496/8647470737a3f2f2777777e266163747d61696c65737562736f6e64756e647e236f6d6f20727f68797f293162353734613662623132313538393931603261383632326730356435653365656665633163643265683031353839383664323835626261626665666660373f2836343734373037333731633662366235373233303330333233343331333033356233363437356233373536356634363736323739363436356235663536343736623737363636623666303735363566366335373037356634633364366638333435303533333236313336663934356633333937313538353535343739333167313431333535333431353636323534623233323434643234333435373137356635373236343535373434373634333733346232333234303333333637303733363634373736663636363637363733343739363462323336343037353734353035303334343166323430373934313732343137333334663462323332343337313434343233313431333466303538353234326632373935383339373566343636333536373534623233323431673167363531673934393534353335316731653033346635353666303734663165353331353337336637373837346232333234346639373137393339333137323638353135383439353834333735373664366431673137326434623233363432343133373636353236313530333035333631673137363336343433393535373936373733333334353333643037363737343033373333363133313435353735346435373266336432363464316635353633313733373235313534643462323336343734313435663566303334623233363434643133353733343736316738373666363435373835343735353635333730373335363730373435333630353666313439373436313738353137333437353666393731333734393334363035303534623233363433333935383431353462333334343f2f60756e6/open" alt="" width="1" height="1" border="0" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-right:0px !important;margin-bottom:0px !important;margin-left:0px !important;padding-top:0px !important;padding-right:0px !important;padding-bottom:0px !important;padding-left:0px !important;" class=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px"><span class=""></span></span></span><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">_______________________________________________</span></span><br class=""></div>
<div class=""><span class="font" style="font-family:Helvetica"><span class="size" style="font-size:12px">swift-evolution mailing list</span></span><br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</blockquote></div>
</div>
</div>
</div>
</blockquote><div class=""> </div>
</div>
</div>
</blockquote></div>
</blockquote><div class=""> </div>
</div>
</div></blockquote></div><br class=""></body></html>