[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names
Jacob Bandes-Storch
jtbandes at gmail.com
Mon Jul 25 03:07:53 CDT 2016
>
>
> 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?
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.
I'd forgotten about prefix(while:), which apparently isn't implemented yet.
I think I'd prefer if this were named prefix(where:) instead.
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.
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?)
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)?
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]".
They also both support *negative indices *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.
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160725/40944dbe/attachment.html>
More information about the swift-evolution
mailing list