[swift-evolution] Strings in Swift 4

Thu Feb 2 05:06:13 CST 2017

> On Feb 1, 2017, at 9:01 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I had read the discussion live as it happened. And just now I went back to see Jaden’s posts again: there are only a handful, and all are quite brief. To the extent that they “sketched a direction”, I would say no. We should instead base the proposal on ideas laid out by Dave Abrahams, Brent Royal-Gordon, Ben Cohen and several others.

Agree, I definitely didn't set the direction here; I just pointed out a semantic inconsistency. I rather liked Brent's `RangeExpression` idea. It's pretty elegant.

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

> 
> We (meaning Swift Evolution) can define any semantics we like for any operator we like. The simple, elegant, intuitive behavior for one-sided ranges is exactly the “do what I mean” approach as described by many people including Dave Abrahams.
> 
> Want to subscript a collection using a one-sided range? Great! If the fixed bound is inside the collection then go as far as possible (ie. from start or to end), and if it is outside then trap for index out of bounds.
> 
> Want to zip together integers and sequence elements? Great! If the sequence eventually ends then stop when it does, and if not then trap when the integer overflows.
> 

It seems really weird to describe the semantics of the type based on how it is used rather than in isolation. What would the docs for this range even say? It's not infinite (else subscript would trap), but it's not incomplete (else we couldn't iterate over).

> Want to iterate over a one-sided range? Well if the upper end is open then great! “for i in 20...” will loop until it hits a “break” or trap on overflow. We could probably even make “for i in (...20).reversed” work and count down, though we don’t have to.

This made me realize that `x...` and `...x` probably ought to be different types (rather than an enum) if we're going to make the former iterable. (For the record, I still think postfix `...` should be overloaded to return 2 different types so we don't have this semantic issue…)

> 
> In any case, the point remains: if we do add one-sided ranges, we can define any behavior we want for them. And given the opinionated nature of Swift, it follows that we should choose to make them expressive, useful, and enjoyable.
> 

I definitely agree that these ranges are much more lightweight and approachable than the labeled subscript syntax, semantic issues aside.

> Nevin
> 
> 
>> On Wed, Feb 1, 2017 at 10:58 AM, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> > On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> wrote:
>> >
>> > Drafting a proposal sounds like a good idea, to establish all the relevant information in one place. I don’t recall off the top of my head what directions Jaden sketched out, but as long as the proposal hits the high points of the uses and benefits, and summarizes the discussion and alternatives, it should be fine.
>> >
>> > I might suggest using Chris’s terminology of “one-sided range”, because that is both more precise and it renders moot all the “incomplete” vs “infinite” hairsplitting.
>> 
>> I recommend reading through the discussion Xiaodi and I had yesterday, which Jaden chimed in on.  We really do need to make a distinction between incomplete and infinite ranges if we want to support all of the use cases with clean semantics.  This isn’t hair splitting.
>> 
>> >
>> > Nevin
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170202/e0f10c78/attachment.html>