Yes, I am back because I should not leave because I might be afraid for 
negative reactions on what I write.  I try to write and respond as civilized as 
possible and never intended as personal, unless it really is. However there was 
one 
person taking wat I wrote personally so I wrote back very friendly that it was 
not. 
No response, twice. It is not very nice to be ignored when you really make a 
real effort
trying to resolve a misunderstanding. It upset me. that's why I left.
Needed time to recover. The problem lies by The Other One, no longer by me.
Ok, sorry for overreacting.

Please ==snip== the above paragraph (and this line) when responding so that it 
doesn't propagate through
Swift-evolution. It doesn't belong there after this. Thanks.

As most colleagues (that's what I think you all are, spanning two generations 
:o) 
might have noticed, I am not exactly happy with the removal of the classical 
for-loop   ( for ;; )  but the damage has been done, so I will soon 
present a proposal for a better alternative. Working on it.
I find this matter very important.

I do not agree with the for-loop removal proposal authored by Erica Sadun,

Important: 
I would like to emphasize again that what I write is not intended personally. 

Also I realize that I am a bit late on this subject, but that is because I was 
not here back then.

I wil go through it point by point and try to explain why IMHO I think this is 
not a good proposal. 
---------------------

Evaluating proposal SE-0007
Remove C-style for-loops with conditions and incrementers
        •       Proposal:       •       Author(s): Erica Sadun



"The C-style for-loop appears to be a mechanical carry-over from C rather than 
a genuinely Swift-specific construct."

Could you explain to me why what, in your view, is 
    -  a "genuinely Swift-specific construct” ?
    - "not very Swift-like" ?  
- "Swift-typical” ?

"It is rarely used  and not very Swift-like."

This is definitely not true. 
The classical for loop is one of the most frequently used language constructs 
in most programming languages.


"More Swift-typical construction is already available with for-in statements 
and stride." 

Except for collections, these are inconvenient, cumbersome and inefficient  
"work arounds" as described later in my comments in this email.


"Removing for loops would simplify the language."
Removing screw drivers from a toolbox would indeed simplify the toolbox.
So would removing closures, classes, protocols etc. from Swift.
Simplification of a programming language can also have its disadvantages. 

" And starve the most common use-points for -- and ++, which are already due to 
be eliminated from the language."

"The value of this construct is limited and I believe its removal should be 
seriously considered"

There absolutely is no need to remove the for ; ; and also ++ -- from the 
language. These can perfectly well co-exist with other language elements of 
Swift. If you don't want to use them, that's fine, but for most people out 
there who still want to use the for ;; and ++ -- .  


"Swift design supported a shallow learning curve using familiar constants and 
control structures. 
The for-loop mimics C and limits the effort needed to master this control flow."

Yes indeed. It mimics C and also the for-loop or its equivalent in more that 20 
other programming languages.


"Disadvantages of For Loops
        1       Both for-in and stride provide equivalent behavior using 
Swift-coherent approaches without being tied to legacy terminology”

Most language elements in Swift ARE legacy, and that's ok, so one does not have 
to re-invent the wheel again.      

        "2      There is a distinct expressive disadvantage in using for-loops 
compared to for-in in succinctness"

What makes you think so? 

        "3      for-loop implementations do not lend themselves to use with 
collections and other core Swift types.”

Agreed if it concerns collections.  However, they can.  Of course, it is much 
easier and more readable to use  e.g. 'for item in items" for collections.

Please enlighten me:  what "other core-Swift-types" do you refer to? 

        "4      The for-loop encourages use of unary incrementors and 
decrementors, which will be soon removed from the language."
Although the majority of programmers like the ++ and -- operators, I do manage 
to understand why some do not like it. However ++ and -- are very well suited 
for classical for-loops, in fact they even make them more readable... Like so:

 1.  for i = 0;  i <  iterations;     i++  { ...}
or 
  2. for i = 0;  i <  iterations;     i +=  1 { ...}

It looks like the first example is more readable.  But yes, if it were that the 
++ -- would have remained in Swift, and also the classical for-loop,  using ++ 
and -- should probably restricted to be used in for-loops only. 

        "5      The semi-colon delimited declaration offers a steep learning 
curve from users arriving from non C-like languages."

IMHO, this is utter nonsense. Even from those coming from other languages as 
C++, C, if a mere three arguments separated by two semicolons are "a steep 
learning curve" ? Then what to think about using closures, lambda's, classes, 
inheritance, functional programming, protocols etc. ?

"Impact on existing code
A search of the Apple Swift codebase suggests this feature is rarely used."

A search of the Apple Swift codebase is not representative, because the scope 
of this search encompasses only source code made by users of the programming 
language Swift, which is partly still under further development. Faithfully 
representative would it be to search in a wider perspective, which should 
include source code written in variety of programming languages like 
Objective-C, Java, C#, C++, C, PHP , Ruby, Go, Perl, Javascript, Dart, V. 
Basic, Pascal,  PL/1, Cobol, Rexx. Most of this languages have implemented the 
for-loop (or equivalent) . Undoubtedly if one would do a search for for-loop in 
these languages it would become clear that the for-loop is heavily used.  

As a result of removing the classical for loop it is to be expected that lot of 
people might consider thinking twice about switching to Swift, If they have to 
live without (or cumbersome work around) language elements that have proven to 
be very useful for at least a few decades...

How do you arrive at such a conclusion? In this perspective, Erica, I am very 
much interested to know if you have practical experience with using other 
programming languages than Objective C and Swift. Have you built solid 
applications with other systems, IDEs and languages? Also, did you consult 
programmers working with other well established languages? 

"Community members of the Swift-Evolution mail list confirm that it does not 
feature in many pro-level apps and can be worked around for those few times 
when for-loops do pop up."

If one browses through the App Store, one might notice that most apps work with 
collections (e.g. customers, addresses, shopping items, videos, songs. etc.) 
For these kind of applications, the for-in-collection statement in Swift is 
great and well catering for these requirements. The result of this is, that the 
majority of Swift developers will not be aware and not miss the classical 
for-loop (or a new Swift equivalent for it at all)  simply because they do not 
need it.

However, for those that make scientific, engineering, statistical, technical 
and game apps, the lack of a simple but versatile iteration statement, which in 
most cases can be compiled down to a simple and very fast assembler loop is 
nothing less than a disaster.

E.g. For the purpose of performance testing, in an Apple TV SceneKit app I am 
currently building, I did replace replace the classical for-loop by a "for in 
x.stride(..."  for coordinate calculations. Performance dropped to about 45%, 
this is unacceptable.  The compiler cannot get rid of this. Working with a 
collection based for-in will nearly always be twice as slow, for the simple 
reason that the contents of the collection it has to process are by definition 
unpredictable.   

In your proposal you offered the following example. I do not know where you 
found this horrible piece of code. However, in this case it is not the for-loop 
that is so bad, but the complete function. There are many better and well 
structured classical for-loops to be found everywhere. I cannot deflect my 
impression that you might have selected this particularly bad example solely to 
amplify your proposal's case. 
"
char *blk_xor(char *dst, const char *src, size_t len)
{
 const char *sp = src;
 for (char *dp = dst; sp - src < len; sp++, dp++)
   *dp ^= *sp;
 return dst;
}
"
Again, this is a extremely bad C Example, infested with (at least to me) 
unclear pointer usage. (Luckily in Swift there are (or should be) no pointers) 
Somewhere in this messy example, yes, a for-loop can be found. Notice that the 
for-loop itself is relatively simple and straightforward. Also, the fact that 
this for-loop deploys two value incrementors instead of one, is in this 
particular context not really all that bad.  


In my opinion, the Swift equivalent you offer, does not look much better:

"
func blk_xor(dst: UnsafeMutablePointer<CChar>, src:
UnsafePointer<CChar>, len: Int) -> UnsafeMutablePointer<CChar> {
   for i in 0..<len {
       dst[i] ^= src[i]
   }
   return dst
}

A search of github's Swift gists suggests the approach is used primarily by 
those new to the language with minimal language skills and is abandoned as 
language mastery is achieved.
"
Another subjective assumption and almost insulting for those, often with years 
of experience, who deploy the classical for-loop intensively and really knowing 
what they are doing.

My conclusion:
Although the proposal has been accepted. I would like to see it withdrawn 
because the arguments brought forward are highly subjective, 
not thoroughly analyzed and in some cases even false. 
Furthermore, a proposal should be based on facts, not assumptions. 

Kind Regards
TedvG.




_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to