<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Feb 2, 2017, at 7:32 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It's not infinite (else subscript would trap)</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>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.</span><br><span></span><br><span>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.</span><br><span></span><br><span>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.</span><br><span></span><br><span>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.</span><br><span></span><br><span>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).</span><br></div></blockquote><br><div>The difference between Range and CountableRange (which I'm desperate to eliminate using conditional conformances) has already been a source of deep frustration for <u>many</u> 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.</div><div><br></div><div>--Dave</div></body></html>