[swift-evolution] Strings in Swift 4
james.froggatt at me.com
Sun Jan 22 19:14:19 CST 2017
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:
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?
------------ Begin Message ------------
MsgID: <0A458383-2415-4ED4-AD28-88393A671A34 at nondot.org>
> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> on Fri Jan 20 2017, Joe Groff <swift-evolution at swift.org> 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.
swift-evolution mailing list
swift-evolution at swift.org
------------- End Message -------------
More information about the swift-evolution