[swift-evolution] Feature proposal: Range operator with step

[Xiaodi Wu]

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.Re hypothetical Countable protocol: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.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?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?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?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:)`.
From: Dave Abrahams via swift-evolution <swift-evolution at swift.org>
Sent: Friday, March 25, 2016 8:11 PM
Subject: Re: [swift-evolution] Feature proposal: Range operator with step
To:  <swift-evolution at swift.org>



on Fri Mar 25 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> Ah, I think the conceptual muddle arises in the plan
> then. Specifically, I'd argue that not all Ranges with Strideable
> bounds should conform to Collection.
>
> Conceptually, whether a type can be advanced by some distance
> (guaranteed by Strideable) is orthogonal to whether a type has an
> obviously correct increment when calling next() on its iterator. Thus,
> although *strides* with Strideable bounds should obviously conform to
> Collection, Ranges that conform to Collection should be constrained to
> types which imply that the Range represents a countable set (as the
> mathematicians say) of numbers.

I think any countable set should be OK, regardless of whether the
elements are numbers.  Ranges of UnsafePointers, for example, are
countable.

> This distinction may come in handy for implementing strides that don't
> accumulate error. Striding through a Range that represents a countable
> set of elements shouldn't accumulate error and we can use what we
> already have--i.e. increment the current value every iteration without
> inspecting the value of the starting bound. Striding through a Range
> that represents an uncountable set of elements definitely requires
> reckoning from the starting bound every iteration.  

So, what does this Countable protocol look like?  It seems like it would
bring back the Index protocols that are otherwise obviated by this
plan... not a jolly prospect.

-- 
Dave

_______________________________________________
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/20160326/1ce29219/attachment.html>