Sent from my iPad
> On Feb 2, 2017, at 7:32 AM, Matthew Johnson <[email protected]> wrote:
>
>
>>> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution
>>> <[email protected]> wrote:
>>>
>>> It's not infinite (else subscript would trap)
>>
>> I'm not necessarily a fan of the idea of allowing you to iterate over an
>> `IncompleteRange`, but I have to ask: What do you imagine an infinite
>> sequence of integers would do when it tried to go past the `max` value? As
>> far as I can tell, trapping is the *only* sensible possibility.
>
> I don’t think anyone is disputing this right now. The discussion is whether
> `IncompleteRange` and `InfiniteRange` are distinct concepts which should be
> modeled or whether they can be adequately represented by a single type.
>
> In order to iterate a range you must know both bounds (even if one is
> infinite). When we have a one-sided range with a bound that is countable and
> we allow it to conform to Sequence we are implicitly acknowledging it is an
> infinite range rather than an “incomplete” range.
>
> If you have a range with an infinite upper bound (i.e. a one-sided range with
> a countable Bound) and apply the usual semantics of a collection subscript
> operation the result would necessarily trap because the upper bound is out of
> bounds.
>
> We obviously don’t want this behavior. Instead we want the upper bound to be
> clamped to the index preceding `endIndex` as a part of the subscript
> operation. For an infinite range this is equivalent to a very special case
> clamping behavior. Special case clamping behavior like this is questionable
> on its own, and especially questionable if we ever add `InfiniteCollection`
> (which Ben mentioned in a footnote to his post) where subscripting with an
> infinite range would be a perfectly valid operation that produces an infinite
> slice.
>
> If instead, we have a distinct type for `IncompleteRange` we don’t need a
> subscript overload with this kind of special case behavior. There would not
> be a subscript that accepts `InfiniteRange` at all (for now - if we add
> `InfiniteCollection` later it probably *would* have one). Instead, we would
> have a subscript that accepts `IncompleteRange` with the obvious semantics of
> filling in the missing bound with the last valid index (or `startIndex` if we
> also support incomplete ranges that only specify an upper bound).
The difference between Range and CountableRange (which I'm desperate to
eliminate using conditional conformances) has already been a source of deep
frustration for many users. From a pure usability standpoint the idea of
creating more distinctions in the type system between similar ranges is
unfathomable to me. Doing so on grounds like those described above seems like
it would represent a blatant case of theoretical purity winning out over
practical considerations, which runs counter to the spirit of Swift.
--Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
