[swift-evolution] Strings in Swift 4

[Xiaodi Wu]

On Tue, Jan 31, 2017 at 5:58 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Jan 31, 2017, at 5:20 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>>
>> I think it’s fair to say that we get to decide on the semantics of
>> postfix `…`.  “a range with no upper bound” is very reasonable, but
>> wouldn’t another reasonable semantics be “all the rest”, meaning that there
>> *is* an upper bound (the greatest possible value).
>>
>
> "All the rest" is by itself insufficient so far as semantics: all the rest
> _of what_? Supposing that our supplied lower bound is an integer, it must
> be all the rest of the integers. It cannot be all the rest of whatever,
> where whatever might be a collection that you try to subset with `0...`.
> (Recall that collections move indices, but indices know nothing about the
> collections.) It would be exceeding fuzzy for postfix `...` to mean "all
> the rest of whatever I want it to mean"--that, almost tautologically, has
> no semantics at all.
>
>
> Under the latter semantics, a `for i in 0…` loop would terminate after
>> reaching Int.max.  This is probably not what the user intended and would
>> still crash when used in David’s example, but it’s worth considering.
>>
>
> OK, I'm borderline fine with `0... == 0...Int.max`. It at least provides
> some semantics (i.e., we're saying `...` refers to all the rest of the
> values representable by the type used for the lower bound) [**]. But
> Jaden's point still stands, since it would only be consistent if `for i in
> arr[0...]` then traps after `arr.count` just like `for i in
> arr[0...Int.max]` would do. Otherwise, we really are fudging the semantics.
>
>
> If we really want to be honest about the information a value produced
> using postfix `…` carries, it is a partial range with only the lower bound
> specified.  This allows us to assign meaning to that partial range using
> additional context:
>
> * When it is possible to increment Bound directly could be interpreted as
> an (near?) infinite sequence that either terminates or traps when it
> reaches an unrepresentable value.
> * When Bound is an index and the partial range is used as a subscript
> argument it can be interpreted to mean “to the end of the collection”.
>

These are two very different semantics. One says, `i...` is a range with no
upper bound; the other says, `i...` is a lower bound of something. The
objection is twofold. In the first place, those shouldn't be spelled the
same way. In the second place, the "lower bound of something" is already
adequately accommodated by using, well, the actual lower bound. Well, also,
the "range with no upper bound" isn't very useful in practice, especially
if the only compelling use case is one for replacing an existing API that,
well, there is no consensus yet to replace.

This still leaves us with an out of bounds crash in David’s example that
> iterates over a partial range.  This is an artifact of `Array` using Int as
> it’s `Index` rather than an opaque type that does not allow users to
> increment it directly rather than using a collection.
>
> Is the problem in David’s example really that different than the ability
> to directly index an array with any `Int` we want?  It’s not the kind of
> thing that developers would do frequently.  The first time they try it they
> will get a crash and will learn not to do it again.
>
> I’m not necessarily arguing one way or the other.  I’m simply pointing out
> that “partial range” is a perfectly reasonable semantics to consider.
>
>
> [**] It is not perfectly consistent semantically because, as was discussed
> in threads about our numeric protocols, our integer types are supposed to
> model all integers, not just the ones that happen to be representable. Our
> model is imperfect because not all integers fit into finite memory, but
> that's a modeling artifact and not intentional semantics. IIUC, it would be
> otherwise difficult to give a good accounting of, say, the semantics of
> addition if arithmetic overflow were an intentional part of the semantics
> and not an artifact.
>
>
> I haven’t followed all of the details of the numeric protocol
> discussions.  With this in mind, I agree with your proposed semantics of
> trapping after `Int.max` as it sounds more consistent with this intent.
>
>
> I’m not sure if you read Ben’s post regarding `enumerated` or not, but he
>> gave the example of `zip(0…, sequence)` as a more general replacement for
>> `enumerated`.  IMO, he makes a pretty strong case for this.
>>
>>
>>
>> - Dave Sweeris
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> 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/20170131/7058b62a/attachment.html>