[swift-evolution] [Proposal] Conventionalizing stride semantics

[Xiaodi Wu]

Do all types that can be arguments for stride(...) conform to
ForwardIndexType such that they can be the end points of a Range? How
about the other way round? The documentation available online does not
make it easy to figure this out.


On Thu, Mar 3, 2016 at 10:23 AM, Erica Sadun via swift-evolution
<swift-evolution at swift.org> wrote:
> 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> 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.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>