[swift-evolution] Strings in Swift 4

[Chris Lattner]

> 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.

-Chris