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

[Dave Abrahams]

on Wed Apr 06 2016, Howard Lovatt <howard.lovatt-AT-gmail.com> wrote:

> Dijkstra specifically said that in Mesa it was a bad idea to include anything
> other than `..<` the relevent quote is:
>
> "Extensive experience with Mesa has shown that the use of the other three
> conventions has been a constant source of clumsiness and mistakes, and on
> account of that experience Mesa programmers are now strongly advised not to use
> the latter three available features. I mention this experimental evidence —for
> what it is worth— because some people feel uncomfortable with conclusions that
> have not been confirmed in practice."
>
> In the above quote the first convention is `..<` and the other three are `<..`,
> `...`, and `<.<` respectively. Therefore he is suggesting that even `...` should
> not be included.

He was talking about ranges of integer indices, though, and even
more-specifically about how to address arrays.  Range<Bound> is a more
general concept that applies to much more than indices.  Once you
involve floating point (and rationals, and patterns for matching,
e.g. UnicodeScalar("a")..."z"), the conclusions no longer apply.


> Personally I would go against Dijksra's advice and include all 4 as operators,
> however if Dijkstra is followed and only `..<` remains then the 'lesser' cases
> could be covered with an init on Range:
>
> init Range(first: T, isFirstIncluded: Bool = true, last: T, isLastIncluded: Bool
> = true, stride: Int = 1)
>
> On Thursday, 7 April 2016, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>     on Wed Apr 06 2016, Brent Royal-Gordon <swift-evolution at swift.org> wrote:
>
>     >> From a purely numerically aesthetic point of view, I'd much prefer ranges
>     to be
>     >> openable and closable at both ends.
>     >>
>     >> My primary use-case has been teaching math using playgrounds but I'm sure
>     >> there are lots of other real-world situations more specific to common
>     numerical
>     >> method tasks.
>     >
>     > By coincidence, a Perl hacker I know commented on Twitter yesterday
>     > that he thought 1-based arrays were the way to go in the 21st
>     > century. Somebody replying to that suggestion linked to a note by
>     > Dijkstra that's relevant to this conversation:
>     > <https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html>
>     >
>     > I'd suggest everyone in this discussion should read it—it's only about 700
>     words—but to summarize:
>     >
>     > 1. The semantic Swift refers to as `..<` is the most natural range
>     convention.
>     > 2. Relatedly, zero-based indexing is the most natural indexing convention.
>     >
>     > If we agree with Dijkstra's logic, then the only reason to support
>     > `>..` is for ranges where start > end—that is, when we're constructing
>     > a reversed range.
>
>     I (am familiar with and) agree with Dijkstra's logic, but not with your
>     conclusion about it. The fact that one representation is more natural
>     for most common computing tasks doesn't mean it's not worth supporting
>     the other representations.
>
>     > But if we decide to support striding backwards by using a forward
>     > range and a negative stride, then that covers the reverse use
>     > case. Thus, we would need neither additional range operators, nor
>     > reversed ranges.
>     >
>     > As for the `range.striding(by:)` vs `stride(over:by:)` question, my
>     > concerns there are, to be honest, mainly aesthetic. The need for
>     > parentheses around the range operator is more or less unavoidable, but
>     > I think they make the construct very ugly. However, I also think that
>     > the `stride(over:by:)` syntax (or, for that matter
>     > `stride(from:to:by:)`) look more constructor-y (they are only *not*
>     > constructors now because of the overloading), and I think it opens us
>     > up to parallel constructs like the `induce(from:while:by:)` function
>     > I've been working on.
>
>     --
>     Dave
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org
>     https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave