<div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">I'd reply inline but I'm working around some technical limitations on the go here. Agreed that anything countable should be good for a Range that conforms to Collection. Well, anything finite, maybe. See below about countably infinite ranges.</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">Re hypothetical Countable protocol:</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">I'm not advocating for another protocol for the numeric type. I'll take your word for it that they aren't jolly, though I don't know why.</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">The issue as I see it is this: currently, Range is documented as a collection of *discrete* index values. If Intervals are going away, does a Range<Float> model a countable set of Floats with unit stride, a finite set of Floats in the technical sense that there exists only a finite set of representable numbers, or an uncountable set?</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">The former two preserves the current definition of Range as a collection of discrete values but may be astonishing to users. But, if we agree that the last scenario is most intuitive, how then can we make the distinction between a "Range" that represents an uncountable set of things with an upper and lower bound and one that represents a countable set of things?</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><div id="compose" style="padding-right: 20px; padding-bottom: 8px; padding-left: 20px;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Thinking more on this, expanding Range to floating point types opens you up to another inconsistency. Can the bounds be -inf and inf? I don't see why that should be a problem for an Interval, but now we're in for some trouble if you want it for a Range that can be strided through. How about 0.0 and inf? That makes sense to allow. But why should the ranges I'm allowed to specify be constrained by what makes sense to stride?</span></div></div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;">So the more I think about it, the more I'm convinced that the logic for what Range-Interval hybrids can be strided through can't neatly accommodate floating point types. If you merge Range and Interval, I still want to be able to specify `-Double.infinity..<Double.infinity`. But if I can do that, then Range<Double> shouldn't even have `striding(by:)`.</div><div id="compose" contenteditable="true" style="padding-left: 20px; padding-right: 20px; padding-bottom: 8px;"><br></div><div class="gmail_quote">From: Dave Abrahams via swift-evolution <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="1">swift-evolution@swift.org</a>><br>Sent: Friday, March 25, 2016 8:11 PM<br>Subject: Re: [swift-evolution] Feature proposal: Range operator with step<br>To: <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="3">swift-evolution@swift.org</a>><br><br><br><br>on Fri Mar 25 2016, Xiaodi Wu <<a dir="ltr" href="http://xiaodi.wu-at-gmail.com" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5">xiaodi.wu-AT-gmail.com</a>> wrote:<br><br>> Ah, I think the conceptual muddle arises in the plan<br>> then. Specifically, I'd argue that not all Ranges with Strideable<br>> bounds should conform to Collection.<br>><br>> Conceptually, whether a type can be advanced by some distance<br>> (guaranteed by Strideable) is orthogonal to whether a type has an<br>> obviously correct increment when calling next() on its iterator. Thus,<br>> although *strides* with Strideable bounds should obviously conform to<br>> Collection, Ranges that conform to Collection should be constrained to<br>> types which imply that the Range represents a countable set (as the<br>> mathematicians say) of numbers.<br><br>I think any countable set should be OK, regardless of whether the<br>elements are numbers. Ranges of UnsafePointers, for example, are<br>countable.<br><br>> This distinction may come in handy for implementing strides that don't<br>> accumulate error. Striding through a Range that represents a countable<br>> set of elements shouldn't accumulate error and we can use what we<br>> already have--i.e. increment the current value every iteration without<br>> inspecting the value of the starting bound. Striding through a Range<br>> that represents an uncountable set of elements definitely requires<br>> reckoning from the starting bound every iteration. <br><br>So, what does this Countable protocol look like? It seems like it would<br>bring back the Index protocols that are otherwise obviated by this<br>plan... not a jolly prospect.<br><br>-- <br>Dave<br><br>_______________________________________________<br>swift-evolution mailing list<br><a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">swift-evolution@swift.org</a><br><a dir="ltr" href="https://lists.swift.org/mailman/listinfo/swift-evolution" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="7">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br><br><br></div>