on Wed Apr 06 2016, Brent Royal-Gordon <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
