<div dir="ltr">I am also +1.<div><div><br></div><div><br></div><div>On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>I’m still curious how postfix `…` would impact our options for variadic generics and tuple unpacking in the future.</blockquote><div><br></div><div><br></div><div>Somebody who happens to have originally created Swift addressed this point last week:</div><div><br></div><div><br></div><div>On Wed, Jan 25, 2017 at 8:49 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br class="gmail-Apple-interchange-newline">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.</div><div><br></div><div>-Chris</div></div></blockquote></div><div><br></div><div><br></div><div>I think we should start a new thread for the discussion of incomplete ranges though.<br></div><div><br></div><div>Nevin</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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]`.<br>
><br>
> There's a lot I dislike about `subscript(upTo/through/from:)<wbr>`:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 3. Neither Stdlib nor the Apple frameworks currently contain *any* labeled subscripts, so this design would be unprecedented in the core language.<br>
><br>
> 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.<br>
><br>
> 5. The argument label solution solves the immediate problem, but doesn't give us anything else.<br>
><br>
> To understand what I mean by #5, consider the implementation. The plan is to introduce a `RangeExpression` protocol:<br>
><br>
> protocol RangeExpression {<br>
> associatedtype Bound: Comparable<br>
> func relative<C: Collection(to collection: C) where C.Index == Bound -> Range<Bound><br>
> }<br>
><br>
> And then reduce the many manually-generated variants of `subscript(_: Range<Index>)` in `Collection` to just two:<br>
><br>
> protocol Collection {<br>
> ...<br>
> subscript(bounds: Range<Index>) -> SubSequence { get }<br>
> ...<br>
> }<br>
><br>
> extension Collection {<br>
> ...<br>
> subscript<Bounds: RangeExpression>(bounds: Bounds) where Bounds.Bound == Index -> SubSequence {<br>
> return self[bounds.relative(to: self)]<br>
> }<br>
> ...<br>
> }<br>
><br>
> This design would automatically, source-compatibly, handle several different existing types you can slice with:<br>
><br>
> * ClosedRange<br>
> * CountableRange<br>
> * CountableClosedRange<br>
><br>
> Plus the new types associated with incomplete ranges:<br>
><br>
> * IncompleteRange<br>
> * IncompleteClosedRange<br>
><br>
> 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:<br>
><br>
> myString[.startIndex + 1 ..< .endIndex - 1]<br>
><br>
> This strikes me as a pretty cool thing that some people might want.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
+1 in general. But I’m still curious how postfix `…` would impact our options for variadic generics and tuple unpacking in the future.<br>
<br>
><br>
> --<br>
> Brent Royal-Gordon<br>
> Architechies<br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div></div></div>