[swift-evolution] Feature proposal: Range operator with step
dabrahams at apple.com
Wed Apr 6 18:37:59 CDT 2016
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
> >> 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
> > 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.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution