I am also +1.
On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution < [email protected]> wrote: > > I’m still curious how postfix `…` would impact our options for variadic > generics and tuple unpacking in the future. Somebody who happens to have originally created Swift addressed this point last week: On Wed, Jan 25, 2017 at 8:49 PM, Chris Lattner via swift-evolution < [email protected]> wrote: > > In any case, it seems like an obviously good tradeoff to make the syntax > for variadic generics more complicated if it makes one sided ranges more > beautiful. > > -Chris > I think we should start a new thread for the discussion of incomplete ranges though. Nevin On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution < [email protected]> wrote: > > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
