<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md</a><br><br>
* What is your evaluation of the proposal?<br></blockquote><div><br></div><div>+1 on drop{First,Last}() → removing{First,Last}().</div>+1 on drop{First,Last}(_:) → removing{Prefix,Suffix}(_:).<div>+1 on drop(while:) → removingPrefix(while:).</div><div>+1 on starts(with:[by:]) → hasPrefix(_:[by:]).</div><div>+1 on index({of:,where:}) → firstIndex({of:,where:}).</div><div>+1 on prefix and postfix versions of ..< and the prefix version of the ... operator. For a while I thought I might prefer labeled subscripts, but after writing them out I agree the operators are better.</div><div><br></div><div>The rest is a stream of consciousness:.</div><div><br></div><div>I don't think postfix ... is necessary. When does one ever combine a ClosedRange with endIndex?</div><div><br></div><div>I don't agree that "drop" sounds particularly scary, but I'm fine with "removing" as an alternative to "drop"/"dropping". Scatologists will be disappointed, I'm sure.</div><div><br></div><div>I'd forgotten about prefix(while:), which apparently isn't implemented yet. I think I'd prefer if this were named prefix(where:) instead.</div><div><br></div><div>I'm struggling a little with the distinction between length-based and index-based methods/subscripts. Are "prefix(_ length: Int)" and "prefix(upTo end: Index)" really different enough that one of them should be a subscript and the other a method? The same question applies to prefix(through:) and suffix(from:). I kinda wish these could all be methods or all subscripts.</div><div><br></div><div>I have to say I don't fully understand the need for (or benefits of) RangeExpression and the relative(to:) API (perhaps because I don't have much experience using the most recent collection/index/range APIs). Since the conforming type's Bound is already required to be the collection's Index, it seems pointless to have an API to access this as a Range...there should just be Collection subscript methods which accept the conforming types. I suppose it's nice to get all these for free by implementing just one subscript function (excepting the current lack of generic subscripts)...but is it even possible to express every RangeExpression as a Range? What about a ClosedRange<Int> whose upperBound is Int.max? (Wasn't that the whole point of introducing ClosedRange in the first place?)</div><div><br></div><div>Random question: why do we have both removeFirst and popFirst? ...on further reading I see you covered this in Future Directions. I'd be happy to discuss merging these. I wonder if it's important to do for Swift 3 (although we're basically out of time)?</div><div><br></div><div>The name IncompleteRange makes sense, but could be a little misleading if ..<(Bound?,Bound?) is called with two non-nil operands: based on my reading, it sounds like the returned IncompleteRange wouldn't actually change when you call completed(by:) (since it's not actually incomplete). However, I can't come up with any better naming suggestions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?<br></blockquote><div><br></div><div>Mostly. Not sure there's enough consistency between subsequence-length-based and index-based APIs, namely that prefix(upTo:) becomes a subscript but prefix(_:) doesn't.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><div><br></div><div>I've used Python and Mathematica, which both have functionality similar to "incomplete range subscripts":</div><div><br class=""> Python: <a href="http://stackoverflow.com/a/509295/23649">http://stackoverflow.com/a/509295/23649</a><br></div><div> Mathematica: <a href="https://reference.wolfram.com/language/ref/Span.html" target="_blank">https://reference.wolfram.com/language/ref/Span.html</a></div><div><br></div><div>Based on my experience there, this is a good first (second?) step for Swift to take.</div><div><br></div><div>Both Mathematica and Python support a <b>stride</b> as well as start/end indices in their subscripting syntax. It would be nice for Swift to support something like this, but some versions of that would require custom ternary operators (or weird intermediate types to fake a custom ternary operator). We might also consider labelled multi-argument subscripts like "collection[start..<end, by: 2]".</div><div><br></div><div>They also both support <b>negative indices </b>which count from the end. Swift's suffix-based APIs are limited; I'd like to see an in-depth consideration of this down the line. Now is probably not the time, unless anyone can think of reasons it would affect the syntax/naming we choose in this proposal.</div><div><br></div><div>(It's also interesting to note that Mathematica's subscripts (<a href="https://reference.wolfram.com/language/ref/Part.html">Part</a>) support multi-dimensional arrays: matrix[[3;;4, -5;;]] would be the submatrix containing the last 5 entries in rows 3 and 4 of the original matrix.)</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div><br></div><div>A mostly-thorough reading of the proposal.</div></div></div></div>