Just out of curiosity, what are the use-cases for an infinite sequence (as opposed to a sequence which is bounded to the type’s representable values)?
Thanks, Jon > On Feb 2, 2017, at 7:52 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > > Sent from my iPad > > On Feb 2, 2017, at 7:32 AM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution >>>> <[email protected] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
