> On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution >> <[email protected]> wrote: >> >> Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. >> It also yields the sensible result that `arr[from: i][upTo: j] == arr[upTo: >> j][from: i] == arr[i..<j]`. > > There's a lot I dislike about `subscript(upTo/through/from:)`: > > 1. We have not previously been very satisfied with how understandable these > labels are—for instance, we fiddled around with them a lot when we were > looking at `stride(from:to/through:by:)` in Swift 3, and eventually settled > on the originals because we couldn't find anything better. I don't think > entrenching them further makes very much sense. > > 2. The fact that you *can* write `arr[from: i][upTo: j]`, and that this is > equivalent to both `arr[upTo: j][from: i]` and `arr[i..<j]`, seems a bit > weird. We aren't typically in the habit of providing redundant APIs like this. > > 3. Neither Stdlib nor the Apple frameworks currently contain *any* labeled > subscripts, so this design would be unprecedented in the core language. > > 4. After a new programmer learns about subscripting with two-sided ranges, > removing one of the bounds is a straightforward extension of what they > already know. The argument label solution is more ad-hoc. > > 5. The argument label solution solves the immediate problem, but doesn't give > us anything else. > > To understand what I mean by #5, consider the implementation. The plan is to > introduce a `RangeExpression` protocol: > > protocol RangeExpression { > associatedtype Bound: Comparable > func relative<C: Collection(to collection: C) where C.Index == > Bound -> Range<Bound> > } > > And then reduce the many manually-generated variants of `subscript(_: > Range<Index>)` in `Collection` to just two: > > protocol Collection { > ... > subscript(bounds: Range<Index>) -> SubSequence { get } > ... > } > > extension Collection { > ... > subscript<Bounds: RangeExpression>(bounds: Bounds) where > Bounds.Bound == Index -> SubSequence { > return self[bounds.relative(to: self)] > } > ... > } > > This design would automatically, source-compatibly, handle several different > existing types you can slice with: > > * ClosedRange > * CountableRange > * CountableClosedRange > > Plus the new types associated with incomplete ranges: > > * IncompleteRange > * IncompleteClosedRange > > Plus anything else we, or users, might want to add. For instance, I have a > prototype built on `RangeExpression` which lets you write things like: > > myString[.startIndex + 1 ..< .endIndex - 1] > > This strikes me as a pretty cool thing that some people might want. > > Similarly, IncompleteRange and IncompleteClosedRange can most likely be put > to other uses. They could easily fill a gap in `switch` statements, which > don't have a good way to express open-ended comparisons except with a `where` > clause. As some have mentioned, when applied to a `Strideable` type they > *could* be treated as infinite sequences, although it's not clear if we > really want to do that. And, you know, sometimes you really *do* have a case > where one or both bounds of a range may be missing in some cases; incomplete > ranges are a built-in, batteries-included way to model that. > > To put it simply, slicing with incomplete ranges gives us several valuable > tools we can apply to other problems. Labeled subscripts, on the other hand, > are just another weird little thing that you have to memorize, and probably > won’t.
+1 in general. But I’m still curious how postfix `…` would impact our options for variadic generics and tuple unpacking in the future. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
