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

[Brent Royal-Gordon]

> 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. 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.

-- 
Brent Royal-Gordon
Architechies