[swift-evolution] Strings in Swift 4

[Xiaodi Wu]

On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> Sent from my iPad
>
> On Feb 2, 2017, at 7:11 AM, Matthew Johnson <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."
>  These are *not* the same thing.  A collection's indices* need not
> include every expressible value of the Index type between startIndex and
> endIndex*.
>

Now this is a reasonably convincing argument.

However, the conflation you describe surely comes at a price. I would bet
that if you polled ordinary Swift users, many would assume that being able
to write `myValue[startIndex..<endIndex]` implies that every expressible
value of Index type between startIndex and endIndex indeed exists in the
collection. It is a real misunderstanding made possible by the absence of
documentation to the contrary and, in its absence, the discordance of
actual behavior from the most parsimonious understanding of range semantics.


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

If indeed the desired semantics for ranges is that they should continue to
lack precise semantics, then an agreement that we are going into this
deliberately and clear documentation to that effect is the next best thing,
I suppose.


> In fact, now that I say it, in that respect ranges are not all that
> different any other type: the meaning of a Double or an Array<String> or a
> Bool is also interpreted by the methods to which it is passed, and can have
> completely different results depending on that context.
>

I'm not sure I understand this comment. Surely the semantic meaning of a
Double is not any more or less fluid than the semantics of the number being
modeled (for instance, 42), nor that of a Bool any more or less fluid than
the semantics of truth or falsity. But we are getting far afield here.

What I'm aiming at is that the proposed "one-sided ranges" are fuzzy on
what it is they are modeling. Now, if the community decides that this
ambiguity is a desirable thing, then so be it. I happen to think it isn't
so desirable. But in any case the decision ought to be made on the basis
that the ambiguity is worth it when exchanged for
[intuitiveness/expressiveness/whatever other advantages], not on denying
that there is ambiguity at all.

chillaxing-ly y'rs,
>
> Dave
>
> _______________________________________________
> 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/ce246a60/attachment-0001.html>