[swift-evolution] Strings in Swift 4

[Matthew Johnson]

> On Feb 2, 2017, at 1:19 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Thu Feb 02 2017, Matthew Johnson <swift-evolution at swift.org> wrote:
> 
>>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams <dabrahams at apple.com>
>> wrote:
>>> 
>>> 
>>> 
>>> 
>> 
>>> 
>>> On Feb 2, 2017, at 7:11 AM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>> 
>>>>> 
>>>>>> 
>>>>>> Furthermore, we emphatically do *not* need to make the
>>>>>> distinction you claim between “infinite” and “incomplete” ranges,
>>>>>> which *is* needless hairsplitting.
>>>>> 
>>>>> Strongly disagree, unless you can describe the semantics of the type WITHOUT giving it different semantics depending on how it is used.
>>>> 
>>>> This is the point that convinced me.  I’m going to take a closer
>>>> look at Brent’s `RangeExpression` design which I must admit I only
>>>> skimmed in the earlier discussion.
>>> 
>>> We already have exactly this situation with CountableRange (which
>>> will merge with Range when conditional conformances land).  When
>>> used as a Collection, it means "every index value starting with the
>>> lowerBound and ending just before the upperBound".  When used for
>>> slicing, it means, roughly, "take every one of the collection's
>>> indices that are in bounds.”
>> 
>> I don’t see how the behavior of the following code means roughly “take
>> every one of the collection’s indices that are in bounds”.  Can you
>> elaborate?
>> 
>> let range = 0..<20
>> let array = [1, 2, 3]
>> let slice = array[range] // trap on index out of bounds
> 
> “Roughly” means “I'm leaving out the part that it's a precondition that
> any (explicit) bound must be a valid index in the collection.”  
> 
>>> These are not the same thing.  A collection's indices need not
>>> include every expressible value of the Index type between startIndex
>>> and endIndex.
>> 
>> Sure, but it does appear as if the behavior of slicing assumes that
>> the upper and lower bounds of the range provided are valid indices.
> 
> Properly stated, it's a precondition.  This is a design decision.  We could
> have made slicing lenient, like Python's:
> 
>>>> [1, 2][50]
>     <Exception Backtrace>
>>>> [1, 2][5:10]
>     []
> 
> We thought that in Swift it was more important to catch potential errors
> than to silently accept
> 
>    [1, 2][5..<10]
> 
> we still have the option to loosen slicing so it works that way, but I
> am not at all convinced it would be an improvement.

I agree with the current behavior as it’s consistent with indexing.

Lenient slicing is in the same space as lenient indexing.  It’s easy enough to add lenient wrappers around the standard library’s trapping implementation.

If we ever decided to have both variants one would have to include a label and I don’t think anybody would support labeling the trapping variant (for many reasons).

> 
>> Xiaodi had convinced me that a one-sided range must take a position on
>> whether or not it has an infinite upper bound in order to make sense,
>> but now you’ve changed my mind back.
> 
> Phew!  To be clear:
> 
>  A one-sided range is *partial*.  It *has no* upper bound.

Ha!  I actually used the term “partial range" earlier.  :)

The distinction between having an infinite upper bound and having no upper bound, but still conforming to `Sequence` is pretty subtle.  

Ultimately I think having a really good name (`RangeExpression`) that implies that the usage site determines the meaning is super important to making this work.  Kudos to whoever came up with that name!

> 
>>> The whole point of the name RangeExpression is to acknowledge this
>>> truth: ranges in Swift bits of syntax whose meaning is given partly
>>> by how they are used.
>> 
>> This makes sense and is roughly the position I started with.  I should
>> have read through the archives of this thread more before jumping into
>> the middle of the discussion - I was missing some important context.
>> I apologize for not doing so.
> 
> No apology needed.  I really appreciate how everyone on this list works
> hard to discover the underlying truth in Swift's design.  Without that
> kind of engagement, Swift would be far worse off.
> 
> Thanks, everybody

Agree.  And I really appreciate the willingness of the core team to spend valuable time engaging with the community and helping to illuminate the design.  You have all spent significantly more time thinking about the “underlying truth” of the design than the rest of us!  

> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution