[swift-evolution] Strings in Swift 4

[Thorsten Seitz]

> Am 24.01.2017 um 20:28 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
> 
> 
>> on Sun Jan 22 2017, James Froggatt <swift-evolution at swift.org> 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: <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
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution