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 
<[email protected]>:

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

Reply via email to