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

[Dave Abrahams]

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