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

[Howard Lovatt]

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.

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
> <javascript:;>> 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 <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160407/640350a4/attachment.html>