> On Feb 1, 2017, at 9:15 AM, Nevin Brackett-Rozinsky > <[email protected]> wrote: > > I am also +1. > > > On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[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] <mailto:[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
Thanks for reminding me of this. I generally agree with Chris, but have no idea what the more complicated syntax for variadic generics might look like. I guess what I’m looking for is some indication of what ideas (if any) there are about what this might look like. A sketch of possible directions would be sufficient to answer the questions lurking in the back of my mind. > > > I think we should start a new thread for the discussion of incomplete ranges > though. Yes, I agree. They have been discussed in two different threads now and it really feels like incomplete (and infinite) ranges deserve discussion in their own right. Would it make sense to draft a proposal based on the direction Jaden sketched as a point of focus for the thread (especially to help newcomers get up to speed)? > > Nevin > > > On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > > On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution > >> <[email protected] <mailto:[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] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
