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

[Matthew Judge]

> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution