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

[Xiaodi Wu]

I think my opinion is largely the same. A range is not a stride, and
sometimes we have use for striding backwards, a use case that shouldn't be
penalized. +1 to the free function.

I wouldn't mind, orthogonally, a way to express (a, b] as a range. It just
seems like that should be of use, somewhere.

Finally, orthogonal to all of the above, I'm super eager to end error
accumulation in floating point strides.
On Tue, Apr 5, 2016 at 6:52 PM Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Apr 5, 2016, at 5:22 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
> I don't think that's obvious at all, because 0 ≮ 10
>
>
> Points brought up elsewhere:
>
> * A range does not have direction, it is is an area of variation between
> lower and upper limits.
> * A range does not go from a larger amount to a smaller amount because it
> is not a sequence
> * Much of this problem goes away with striding (as Dave pointed out
> several times, sorry Dave)
>
> After consideration, I have been persuaded to the opinion that
>
>  stride(from: 0, to: -10, by: -1)
>
>
> and
>
>    (-9...0).reverse()
>
>
> both represent the numbers -9, -8,...,0 better than any alternatives I
> have offered. I still
> prefer the stride version for intent and clarity.
>
> That said, I also prefer my revised SE-0051 semantics for better
> representing what strides will
> attempt to do.
>
> -- Erica
> p.s. Thanks all for the patient explanations
>
>
>
>
> _______________________________________________
> 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/20160406/1eb3bb1a/attachment.html>