on Mon Jul 25 2016, Jacob Bandes-Storch <[email protected]> wrote:
>> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md >> >> * What is your evaluation of the proposal? >> > > +1 on drop{First,Last}() → removing{First,Last}(). > +1 on drop{First,Last}(_:) → removing{Prefix,Suffix}(_:). > +1 on drop(while:) → removingPrefix(while:). > +1 on starts(with:[by:]) → hasPrefix(_:[by:]). > +1 on index({of:,where:}) → firstIndex({of:,where:}). > +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. > > The rest is a stream of consciousness:. > > I don't think postfix ... is necessary. When does one ever combine a > ClosedRange with endIndex? +1 There is a use case for it, but IMO it's a corner that doesn't need terse syntax. > I don't agree that "drop" sounds particularly scary, It's scary because it's active. “Dropping” has other issues, as you note below. > but I'm fine with "removing" as an alternative to > "drop"/"dropping". Scatologists will be disappointed, I'm sure. > > I'd forgotten about prefix(while:), which apparently isn't implemented yet. > I think I'd prefer if this were named prefix(where:) instead. +1 > 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. Me too. That was the motivation for my suggestion of x[..<$+n], meaning x.prefix(n). However, that proposal is a failure (I just wrote it wrong above again before correcting myself)! The main point of changing prefix(to:) and suffix(from:) into x[..<i] and x[i..<] is not to make them subscripts, but to re-use the cognitive power users have already invested in range expressions. Writing them as something like x.slice(..<i) and x.slice(i..<), would accomplish that, too. > 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). It collapses a whole raft of overloads into two (except for subscript, because we don't have generic subscript yet, which is a temporary limitation). In general if you want to implement a collection method that takes a range today, you really should implement four overloads. With the introduction of the incomplete ranges it's six or eight. > 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? For the purposes of creating a range of valid indices in a collection, yes. > What about a ClosedRange<Int> whose upperBound is Int.max? (Wasn't > that the whole point of introducing ClosedRange in the first place?) > > Random question: why do we have both removeFirst and popFirst? We don't. > ...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)? > > 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. > >> * Is the problem being addressed significant enough to warrant a >> change to Swift? >> > > Yes. > >> * Does this proposal fit well with the feel and direction of Swift? >> > > 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. > > * If you have used other languages or libraries with a similar >> feature, how do you feel that this proposal compares to those? >> > > I've used Python and Mathematica, which both have functionality similar to > "incomplete range subscripts": > > Python: http://stackoverflow.com/a/509295/23649 > Mathematica: https://reference.wolfram.com/language/ref/Span.html > > Based on my experience there, this is a good first (second?) step for Swift > to take. > > Both Mathematica and Python support a *stride* 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]". There's a point at which we should stop trying to overload subscript syntax and just use stride(...). > They also both support *negative indices *which count from the end. That's another thing I was getting at with x[..<$-n] (a.k.a. x.removingSuffix(ofMaxLength: n)). But again, #FAIL. > 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. > > (It's also interesting to note that Mathematica's subscripts (Part > <https://reference.wolfram.com/language/ref/Part.html>) 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.) > >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? >> > > A mostly-thorough reading of the proposal. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
