[swift-evolution] [Proposal] Conventionalizing stride semantics
Erica Sadun
erica at ericasadun.com
Thu Mar 3 10:23:41 CST 2016
Should ranges drop that precondition then? So they can represent forward and backward progressions?
> On Mar 3, 2016, at 8:10 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>
>
> on Tue Mar 01 2016, Haravikk <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> I still wonder if a better solution might involve the same syntax as ranges currently benefit from, i.e:
>>
>> 0 ..< 10 // [0, 10) with an increment of 1
>> (0 … 10).stride(2) // [0, 10] with an increment of 2
>>
>> The most important change is that the default type for this should be able to handle higher starting indices, e.g:
>>
>> (10 … 0).stride(2) // [10, 0] with a decrement of 2
>
> I like this approach a lot. We have lots of different ways to express
> variations on ranges and intervals today that don't actually involve the
> range operators (including prefixTo, suffixFrom, stride). IMO they
> should.
>
> The one problem I anticipate is that negative strides won't work well,
> because forming (a...b) will have a precondition that a <= b.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/8669102f/attachment.html>
More information about the swift-evolution
mailing list