[swift-evolution] Strings in Swift 4

[Xiaodi Wu]

I entirely agree with you on the desired behavior of `zip(...)`.

However, if you insist on 0... being notionally an infinite range, then you
would have to insist on `for i in 0...` also trapping. Which is not a big
deal, IMO, but will surely make the anti-trapping crowd upset.

The bigger issue is that either you must have a lenient/clamping subscript
for `arr[0...]` or it too must trap, which is not desired. However, if
`arr[0...]` is clamping, then `[1, 2, 3][100...]` would not trap and
instead give you `[]`.

If 0... is regarded as an incomplete range, your example of `zip(...)`
could still trap as desired. It would trap on the notional attempt to
assign someArray.count to IncompleteRange<T>.inferredUpperBound if count
exceeds T.max. With such semantics for 0..., [1, 2, 3][0...] would behave
as expected without the need for leniency, but [1, 2, 3][100...] would trap
as I assume you'd expect. However, it would make no sense to write `for i
in 0...`.

On Tue, Jan 31, 2017 at 21:39 Dave Abrahams <dabrahams at apple.com> wrote:

>
> on Tue Jan 31 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>
> > But that's not getting to the biggest hitch with your proposal. If
> > subscript were lenient, then `arr[lenient: 42...]` would also have to
> give
> > you a result even if `arr.count == 21`.
> >
> > This is not at all what Dave Abrahams was proposing, though (unless I
> > totally misunderstand). He truly doesn't want an infinite range. He wants
> > to use a terser notation for saying: I want x to be the lower bound of a
> > range for which I don't yet know (or haven't bothered to find out) the
> > finite upper bound. It would be plainly clear, if spelled as `arr[from:
> > 42]`, that if `arr.count < 43` then this expression will trap, but if
> > `arr.count >= 43` then this expression will give you the rest of the
> > elements.
>
> I think you do misunderstand.  Notionally, 0... is an infinite range.
> The basic programming model for numbers in swift is (to a first
> approximation), program as if there's no overflow, and we'll catch you
> by trapping if your assumption is wrong.  It doesn't make sense for the
> semantics of 0... to depend on the deduced type of 0 or the
> representable range of Int
>
> for example,
>
>     for x in zip(n..., someArray) {
>
>     }
>
> How many iterations should this give you?  If it doesn't process all of
> someArray, I want a trap.
>
> --
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170201/f2a465b0/attachment.html>