[swift-evolution] Feature proposal: Range operator with step
matthew.judge at gmail.com
Wed Apr 6 20:12:18 CDT 2016
> On Apr 6, 2016, at 17:00, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> on Wed Apr 06 2016, Erica Sadun <swift-evolution at swift.org> wrote:
>>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> Prohibiting StrideTo with floating-point ranges altogether would be
>>> distressing. IMO, it's plenty distressing that backwards
>>> floating-point StrideTo as it currently exists might go away.
>> I wouldn't suggest doing so. I'm just saying that for a half-open interval, there is no max value
>> so it makes no sense mathematically to have a first value and a
>> negative step.
> I don't agree. It seems to me that striding downwards over a half-open
> range r should always begin with r.upperBound - s (modulo any necessary
> adjustments to avoid FP error), where -s is the stride amount. Why is
> that mathematical nonsense?
This doesn't seem intuitive to me at all.
I can think of three interpretations of '(lBound..<uBound).striding(by:-step)':
- start at max value in range that is less than 'uBound'
- start at 'bound - step' (your suggestion)
- start where-ever is needed to end exactly at lBound
None of these interpretations seem intuitive to me.
I agree with Erica that the start point when striding should be an inclusive bound. A negative stride should only work with a closed range (or '<..' if it is defined).
> Another point to consider: striding is also a sensible operation over
> collections, and some ranges are collections. The stride semantics must
> coincide in those cases. I expect that constraint narrows down the
> reasonable semantic choices considerably.
>> You're not so restricted with:
>> * positive steps
>> * closed intervals
>> -- E
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution