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

Thorsten Seitz tseitz42 at icloud.com
Thu Apr 7 01:35:45 CDT 2016

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.


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

More information about the swift-evolution mailing list