[swift-evolution] Strings in Swift 4

[Thorsten Seitz]

> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution <swift-evolution at swift.org>:
> 
> 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: <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.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> )ß
> 
> ------------- End Message ------------- 
> 
> 
> 
> From James
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution