> Am 24.01.2017 um 20:28 schrieb Dave Abrahams via swift-evolution > <[email protected]>: > > >> 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
Ah, that makes sense! -Thorsten > >> ------------ 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
