> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution > <[email protected]>: > > 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.
Good point! > The wording is up for debate, but something like this should be a fair > alternative: > items[from: i] > items[upTo: i] For me that's at least as readable as the range syntax. > > 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? > let x = items[partialRange] //shouldn't this cause an out of bounds error? Good point! Probably this shouldn't be allowed, making the literal range syntax with open ends tied into the subscript which is a bit confusing indeed. -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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
