on Sun Jan 22 2017, James Froggatt <[email protected]> wrote:
> Could we add subscript labels to the list of options? While keeping > the range syntax is appealing, I'm concerned it may cause confusion if > the operators are used out of context. > > The wording is up for debate, but something like this should be a fair > alternative: > items[from: i] > items[upTo: i] If we were to do that, I'd want to drop range notation altogether and just require this for slicing: items[from: i, upTo: j] The point here is to create a single unified idiom that can be used everywhere. > Sorry if this has been covered elsewhere (can't find the answer in > this thread), but my first questions on discovering these operators > (my source of confusion) would be what happens if I try the following: > let partialRange = 0..< //is this an infinite range? It is not a Range, but a RangeExpression with no upper bound. > let x = items[partialRange] //shouldn't this cause an out of bounds error? No, the upper bound is filled in by the collection > ------------ Begin Message ------------ > Group: gmane.comp.lang.swift.evolution > MsgID: <[email protected]> > >> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution >> <[email protected]> > wrote: >> >>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> >>> on Fri Jan 20 2017, Joe Groff <[email protected]> wrote: >>> >>>> Jordan points out that the generalized slicing syntax stomps on '...x' >>>> and 'x...', which would be somewhat obvious candidates for variadic >>>> splatting if that ever becomes a thing. Now, variadics are a much more >>>> esoteric feature and slicing is much more important to day-to-day >>>> programming, so this isn't the end of the world IMO, but it is >>>> something we'd be giving up. >>> >>> Good point, Jordan. >> >> In my experiments with introducing one-sided operators in Swift 3, I >> was not able to find a case where you actually wanted to write >> `c[i...]`. Everything I tried needed to use `c[i..<]` instead. My >> conclusion was that there was no possible use for postfix `...`; >> after all, `c[i...]` means `c[i...c.endIndex]`, which means >> `c[i..<c.index(after: c.endIndex)]`, which violates a precondition >> on `index(after:)`. > > Right, the only sensible semantics for a one sided range with an open > end point is that it goes to the end of the collection. I see a few > different potential colors to paint this bikeshed with, all of which > would have the semantics “c[i..<c.endIndex]”: > > 1) Provide "c[i...]": > 2) Provide "c[i..<]": > 3) Provide both "c[i..<]” and "c[i…]": > > Since all of these operations would have the same behavior, it comes down to > subjective questions: > > a) Do we want redundancy? IMO, no, which is why #3 is not very desirable. > b) Which is easier to explain to people? As you say, "i..< is shorthand for > i..<endindex” is nice > and simple, which leans towards #2. > c) Which is subjectively nicer looking? IMO, #1 is much nicer > typographically. The ..< formulation looks like symbol soup, > particularly because most folks would not put a space before ]. > > There is no obvious winner, but to me, I tend to prefer #1. What do other > folks think? > >> If that's the case, you can reserve postfix `...` for future variadics >> features, while using > prefix `...` for these one-sided ranges. > > I’m personally not very worried about this, the feature doesn’t > exist yet and there are lots of ways to spell it. This is something > that could and probably should deserve a more explicit/heavy syntax > for clarity. > > -Chris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > )ß > > ------------- End Message ------------- > > From James > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
