> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen <[email protected]> wrote: > > Alas, I don’t understand you irritation, > but it is your irritation, not mine.
Well, its quite simple: we are having a discussion here. You are claiming that the collection-based iteration is inherently slower than a classical numerical loop. This is incorrect. I have even sent around some C code that uses different abstractions and shown that it compiles to the same machine code. Yet you are consistently ignoring this. > Please note again, that “for ... in …” always has > some sort of collection type as its argument.. > At run time, the content of a collection > is in most cases unpredictable. Again, incorrect. The simple collections that are relevant to this discussion are based on trivial iterators that can be statically dispatched and inlined by the compiler. They can potentially even be unrolled (although I doubt that Swift optimiser does this kind of optimisation currently). Again, the difference between for(int i = x0; i<x1; i++) and for(int i = iterator->next(); !iterator->endReached, int i = iterator->next()) is just one level of indirection. If the value of iterator->next() is available at the compile time and the compiler can safely assume that the iterator has a unique reference, the code can be inlined, producing the same loop as above > E.g. For similar reasons one could be irritated by > the brave attempts of some of us to supply > most peculiar variants of “Strides", seemingly, > at least as seen from my limited perspective, > to compensate the loss of the classical for-loop’s > facilities… I am not at all a fan of the stride() method because they are weird to read. However, a stride() global function will do the job just fine, as shown by the example of such languages as R and Python, which are used quite prominently in the numerical domain (there the functions are called seq() and range() ) > For the simple reason that there are no collections involved: > I have very clearly described and motivated it. Your description clearly involve numerical sequences. So they perfectly well fall into the domain of sequence-based iteration. > I took the liberty to read about you on the internet. Interesting. Thank you, its very flattering :) > I fail to understand what your > objections are against the presence of > two slightly different for-loop variants > that can co-exist easily and are effective, > each in its own different context? In case I didn’t explain my reasoning clear enough, here is another attempt. Swift already has a very powerful, compact tool that offers a strict superset of the iteration semantics. I simply see no purpose into making the language more verbose and complicated for no particular gain. What you do is argue for having two different syntactic styles for accomplishing exactly the same thing, simply on the grounds of your personal dislike of one of them. Best, Taras _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
