[swift-evolution] For-loop revisited

[Ted F.A. van Gaalen]

Hello Taras
If I am not mistaken, the compiler cannot optimize: 

   for element in collection {}

simply because the contents of the collection are
unknown at compile time.

However, it might be able to do so in this cases where
the contents of the collection are known at compile time, e.g. : 

  1.   for str in [“ape”,”tiger”,”dolphin”,”salmon”] {}

  2.   for n in [1, 12, 34, 65, 78, 3]  {}

or perhaps also for collections declared with ‘let’:

  3.   let words = [“this”,”collection”,”does”,”not”,”change”]
        for str in words {} 

and also when the compiler can determine the sequence
 optimize collection usage completely out of the way e.g.: 
  
  4.   for v in stride(from: v1 to v2 by vstep)

like it can do also with:
 
  5.   for i in v1…v2    // etc.

Ergo: In cases where the contents of a collection is unknown at compile
time the compiler always needs to include instructions to traverse
through a collection. As in my example test, this consumes twice
as much time as a plain loop without a collection.

Even when optimized by a smart compiler, or even
hand-coded. I’d estimate that the difference at run time 
wil be also be something  in the order of 2:1, may even 3:1 
because the compiled for..in.. it needs the collection processing 
instructions in all cases where collection contents cannot be
determined at compile time.


I have sugessted these for variants like so:

   for  x from xmin to xmax by xstep  { }

   for x from xmax to xmin by -xstep  { } 
 
because:
 - no collections are involved/processed in these cases in the first place,
   
- the compiler can optimize it very easily. 
   in fact that logic is (still) already present in the
   Swift compiler to compile all for ;; variants.

- Semantic: to have a clear distinction that one is not working with collections here.

Certainly not the least:

- For the sake of clearness and readability.


Marginal use of for ;; or a new Swift equivalent of it?  

What makes you think so? 

That is definitely not the case!. Please read a lot of source code
in Fortran, C# Delphi, PL/1 C, C++ , Pascal etc. sources
for scientific and technical programming and then try
to imagine how you would rewrite these in Swift with
for ;; removed?  
Currently there is no proper equivalence.

I am a bit worried that there is a tendency to remove
statement elements for Swift, as one cannot be sure
if these are useful or not for specific interest groups.

Swift is (and hopefully remains to be) a general purpose
language, Also, so not especially OOP or FP, both
inclinations should be first-class citizens. 

TedvG


> On 09.03.2016, at 13:21, Taras Zakharko <taras.zakharko at uzh.ch> wrote:
> 
> 
>> On 09 Mar 2016, at 00:01, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> However, in the real world, especially when working with technical 
>> and scientific data and for instance in time critical applications 
>> like 3D presentations fast iterations become a necessity.
> 
> There is no reason why collection-based iteration can’t be as fast as a classical C for loop. The compiler should be able to optimise all the overhead away. , even unroll shorter loops. Maybe it doesn’t do it yet. I’d rather see resources invested into improving the compiler to inline/unroll code better where appropriate rather then introducing additional syntax to support a marginal use case. 
> 
> — Taras
> 
>