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

[Thorsten Seitz]

Dijkstra is talking about intervals of natural numbers, i.e. indices.
Range is much more general than that, including floating point ranges, so Dijkstra's arguments do not apply here.

-Thorsten 

Am 06.04.2016 um 23:41 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:

>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution