Post-Evaluating proposal SE-0007 Remove C-style for-loops


(Ted van Gaalen) #1

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.


(Chris Lattner) #2

Hi Ted,

I know you are trying to be helpful here, but this proposal has already been accepted and implemented. Keep in mind that while the proposal itself is germane and important, it is the community discussion around it, and ultimately the core team decision that led to its removal.

If you would like to see C style for loops brought back, the proper procedural way to do this would be to start a new discussion (which would lead to a formal proposal) to add them to swift. This should include clear and cogent arguments for why the feature is worth adding to swift-that-currently-does-not-have-it, rather than arguing that an accepted proposal has issues.

-Chris

···

On Mar 18, 2016, at 1:28 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

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.


(Patrick Gili) #3

Hi Ted,

I don't think many of us that are active on this mailing list had the opportunity to provide feedback on this proposal review. I very much agree with you on many points that you bring up below. I have spent a lot of time scratching my head wondering why it was so important to remove certain syntax from Swift, such as C-style loops, unary increment, and unary decrement. Leaving them there increases compatibility of C code with Swift, and leaving them there keeps them opt-in. If you don't want to use it, you don't have to. However, the changes definitely force developers to use newer syntax, which runs contrary to the "opt-in philosophy" that the core team has impressed on the community.

I'm going to play devil's advocate though. Will the tools for Swift 3 automatically make the necessary changes to source to comply with the new syntax? If so, is it so bad? I've been using the C language and all of its variants for more than 32 years. Hence, it is easier on my eyes and brain if there is some compatibility there. Personally, I think leaving this syntax in the language eases migration. Although, I've been learning so many new languages over the last decade that it seems to matter less with time. However, I can't seem for the millions of developers that write code for OS X and iOS.

Cheers,
-Patrick

···

On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

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


(Ted van Gaalen) #4

Hello Chris,

Thank you, I know that and agree with you asking me
to follow the usual path in Swift-evolution, of course.

I am currently working on a proposal for a new for-loop variant:

      for v from v1 to v2 [by vstep] [tolerance vtol ] // in [] is optional here

for numerical values.

As you might have noticed I already wrote something about that > a week a go.

I don’t want the classical for-loop back per se, but simply want to bring forward
an appropriate equivalent which fits better in the Swift environment.

I will start a new discussion for this topic as you recommend, next week.

The issue that I have with SE-0007 that it is in my opinion not professional,
for reasons I have mentioned in my conclusion at the end.

That is the main reason I brought it forward.

Kind Regards

-TedvG

···

On 18.03.2016, at 22:18, Chris Lattner <clattner@apple.com> wrote:

Hi Ted,

I know you are trying to be helpful here, but this proposal has already been accepted and implemented. Keep in mind that while the proposal itself is germane and important, it is the community discussion around it, and ultimately the core team decision that led to its removal.

If you would like to see C style for loops brought back, the proper procedural way to do this would be to start a new discussion (which would lead to a formal proposal) to add them to swift. This should include clear and cogent arguments for why the feature is worth adding to swift-that-currently-does-not-have-it, rather than arguing that an accepted proposal has issues.

-Chris

On Mar 18, 2016, at 1:28 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

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.


(Ted van Gaalen) #5

On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:
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...

I also find it of the most importance to keep Swift accessible for all kinds of programmers
from starters to academic.

Graig Federighi said
We think it should be everywhere and used by everyone.

I subscribe to that.

-TedvG

···

On 18.03.2016, at 22:04, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Ted,

I don't think many of us that are active on this mailing list had the opportunity to provide feedback on this proposal review. I very much agree with you on many points that you bring up below. I have spent a lot of time scratching my head wondering why it was so important to remove certain syntax from Swift, such as C-style loops, unary increment, and unary decrement. Leaving them there increases compatibility of C code with Swift, and leaving them there keeps them opt-in. If you don't want to use it, you don't have to. However, the changes definitely force developers to use newer syntax, which runs contrary to the "opt-in philosophy" that the core team has impressed on the community.

I'm going to play devil's advocate though. Will the tools for Swift 3 automatically make the necessary changes to source to comply with the new syntax? If so, is it so bad? I've been using the C language and all of its variants for more than 32 years. Hence, it is easier on my eyes and brain if there is some compatibility there. Personally, I think leaving this syntax in the language eases migration. Although, I've been learning so many new languages over the last decade that it seems to matter less with time. However, I can't seem for the millions of developers that write code for OS X and iOS.

Cheers,
-Patrick

On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #6

Great, thanks!

-Chris

···

On Mar 18, 2016, at 3:58 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

As you might have noticed I already wrote something about that > a week a go.

I don’t want the classical for-loop back per se, but simply want to bring forward
an appropriate equivalent which fits better in the Swift environment.

I will start a new discussion for this topic as you recommend, next week.


(TJ Usiyan) #7

Please… *please* let this lie.

I understand that it will likely cause some specific cases to become more
difficult but, on balance, it was a simplifying change. The syntax that we
do have is clearer to those unfamiliar with programming idioms from other
languages and people *are* familiar with other programming languages have
the tools to construct whatever functionality they feel is missing from the
provided tools.

TJ

···

On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution < swift-evolution@swift.org> wrote:

On Chris’s advice, I’ve spawned this into a new discussion topic, for
which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:

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...

I also find it of the most importance to keep Swift accessible for all
kinds of programmers
from starters to academic.

Graig Federighi said
*We think it should be everywhere and used by everyone.*

I subscribe to that.

-TedvG

On 18.03.2016, at 22:04, Patrick Gili <gili.patrick.r@gili-labs.com> > wrote:

Hi Ted,

I don't think many of us that are active on this mailing list had the
opportunity to provide feedback on this proposal review. I very much agree
with you on many points that you bring up below. I have spent a lot of time
scratching my head wondering why it was so important to remove certain
syntax from Swift, such as C-style loops, unary increment, and unary
decrement. Leaving them there increases compatibility of C code with Swift,
and leaving them there keeps them opt-in. If you don't want to use it, you
don't have to. However, the changes definitely force developers to use
newer syntax, which runs contrary to the "opt-in philosophy" that the core
team has impressed on the community.

I'm going to play devil's advocate though. Will the tools for Swift 3
automatically make the necessary changes to source to comply with the new
syntax? If so, is it so bad? I've been using the C language and all of its
variants for more than 32 years. Hence, it is easier on my eyes and brain
if there is some compatibility there. Personally, I think leaving this
syntax in the language eases migration. Although, I've been learning so
many new languages over the last decade that it seems to matter less with
time. However, I can't seem for the millions of developers that write code
for OS X and iOS.

Cheers,
-Patrick

On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution < > swift-evolution@swift.org> wrote:

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

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


(Dmitri Gribenko) #8

Hi Ted,

Thank you for starting this thread. I agree that removing the C-style
for loop has degraded the readability and clarity of some of numerics
code.

In the feedback to SE-0007 many people have said that they can convert
their code to for-in loops, but I think this actually means that in
code that is typically written in Swift today, loops primarily operate
on sequences and collections. It means that numerics is a domain that
not many people work in. But it is a very important domain
nevertheless, and clarity for numerics code matters at least as much
as it does everywhere else.

I think one way to approach this discussion would be to present
multiple concrete code samples that contain C-style for loops and are
awkward to write without them. We can then try looking for patterns,
generalize and simplify, and discuss possible solutions.

Dmitri

···

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Ted van Gaalen) #9

Hello T.J.
It will be an addition, not a change. The for- statement I will bring forward does not change the existing for-in... at all or any other language element.

-TedvG

···

On 19 Mar 2016, at 00:55, T.J. Usiyan <griotspeak@gmail.com> wrote:

Please… *please* let this lie.

I understand that it will likely cause some specific cases to become more difficult but, on balance, it was a simplifying change. The syntax that we do have is clearer to those unfamiliar with programming idioms from other languages and people *are* familiar with other programming languages have the tools to construct whatever functionality they feel is missing from the provided tools.

TJ

On Fri, Mar 18, 2016 at 5:19 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:
On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:
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...

I also find it of the most importance to keep Swift accessible for all kinds of programmers
from starters to academic.

Graig Federighi said
We think it should be everywhere and used by everyone.

I subscribe to that.

-TedvG

On 18.03.2016, at 22:04, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

Hi Ted,

I don't think many of us that are active on this mailing list had the opportunity to provide feedback on this proposal review. I very much agree with you on many points that you bring up below. I have spent a lot of time scratching my head wondering why it was so important to remove certain syntax from Swift, such as C-style loops, unary increment, and unary decrement. Leaving them there increases compatibility of C code with Swift, and leaving them there keeps them opt-in. If you don't want to use it, you don't have to. However, the changes definitely force developers to use newer syntax, which runs contrary to the "opt-in philosophy" that the core team has impressed on the community.

I'm going to play devil's advocate though. Will the tools for Swift 3 automatically make the necessary changes to source to comply with the new syntax? If so, is it so bad? I've been using the C language and all of its variants for more than 32 years. Hence, it is easier on my eyes and brain if there is some compatibility there. Personally, I think leaving this syntax in the language eases migration. Although, I've been learning so many new languages over the last decade that it seems to matter less with time. However, I can't seem for the millions of developers that write code for OS X and iOS.

Cheers,
-Patrick

On Mar 18, 2016, at 4:28 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

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

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


(Patrick Gili) #10

On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:
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...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language brings them, for good or bad. If this group of people doesn't like a decision made by the community, they can grumble about it for awhile, suck in a deep breath, and move on.

2) Others; this group may be considering using Swift to develop software on other platforms and in other environments. If this group of people doesn't like a decision made by the community, they may think twice and it could significantly impact the uptake by this group of developers. I think it is wise that the community lubricate the transition to Swift as much as possible for this group of developers. I ask if leaving this kind of syntax in the language is so bad? Does it fall in the same category as removing function currying? My gut tells me not, but I could be wrong.

···

On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

I also find it of the most importance to keep Swift accessible for all kinds of programmers
from starters to academic.

Graig Federighi said
We think it should be everywhere and used by everyone.

I subscribe to that.

-TedvG


(Tino) #11

Imho the syntax of the deprecated for-loop was no good fit for Swift, but I've read several rumors about inferior performance of the alternatives…. so, as a basis for further discussion, I'd like to see some reliable numbers:
I expect that every loop can be expressed in Swift 3 with identical runtime and memory characteristics, but I'm not sure if this can be achieved with for-in, instead of a more complicated transformation that uses while.

Arguing about syntax is always subjective, but it's hard to justify the complete removal of the classic for-loop if the "modern" constructs can't compete with it.


(Ted van Gaalen) #12

Yes, thank you Dmitri, I think so too.
Will come back to this later.
TedvG

ted van gaalen

···

On 19 Mar 2016, at 08:46, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi Ted,

Thank you for starting this thread. I agree that removing the C-style
for loop has degraded the readability and clarity of some of numerics
code.

In the feedback to SE-0007 many people have said that they can convert
their code to for-in loops, but I think this actually means that in
code that is typically written in Swift today, loops primarily operate
on sequences and collections. It means that numerics is a domain that
not many people work in. But it is a very important domain
nevertheless, and clarity for numerics code matters at least as much
as it does everywhere else.

I think one way to approach this discussion would be to present
multiple concrete code samples that contain C-style for loops and are
awkward to write without them. We can then try looking for patterns,
generalize and simplify, and discuss possible solutions.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Ross O'Brien) #13

But the discussion is no longer about 'do we really need to take this
feature out?'. The feature is already out. It's deprecated in Swift 2.2.
The discussion is 'is there a compelling reason to put it back in again?'.

We still have for-in loops. We still have repeat while. We still have
forEach. Iteration isn't going anywhere; it just doesn't have this peculiar
semi-colon structure any more. It's a confusing structure for beginning
programmers to learn in the first place, and Swift doesn't use semi-colons
so much.

···

On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution < swift-evolution@swift.org> wrote:

On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> > wrote:

On Chris’s advice, I’ve spawned this into a new discussion topic, for
which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:

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...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language
brings them, for good or bad. If this group of people doesn't like a
decision made by the community, they can grumble about it for awhile, suck
in a deep breath, and move on.

2) Others; this group may be considering using Swift to develop software
on other platforms and in other environments. If this group of people
doesn't like a decision made by the community, they may think twice and it
could significantly impact the uptake by this group of developers. I think
it is wise that the community lubricate the transition to Swift as much as
possible for this group of developers. I ask if leaving this kind of syntax
in the language is so bad? Does it fall in the same category as removing
function currying? My gut tells me not, but I could be wrong.

I also find it of the most importance to keep Swift accessible for all
kinds of programmers
from starters to academic.

Graig Federighi said
*We think it should be everywhere and used by everyone.*

I subscribe to that.

-TedvG

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


(Greg Parker) #14

Let me emphasize this more strongly. *Concrete*, *real-world* examples are quite likely the only way that you are going to get `for(;;)` back or get any sort of semantically-similar syntactically-different replacement.

There have been lots of suggestions. None of them are perfect. If we assume that there is in fact no perfect solution then the only way to proceed is to provide sufficient justification for some imperfect solution.

I'm still waiting for something like this: "We ported our code to Swift 3. Here are 5 reasonable-looking for(;:wink: loop shapes from 150 call sites, and here are their ugly-looking rewrites."

(Personally I think removing for(;:wink: without direct replacement was too aggressive. That view lost. Now its advocates will need to do more work to upend the status quo.)

···

On Mar 19, 2016, at 12:46 AM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

Hi Ted,

Thank you for starting this thread. I agree that removing the C-style
for loop has degraded the readability and clarity of some of numerics
code.

In the feedback to SE-0007 many people have said that they can convert
their code to for-in loops, but I think this actually means that in
code that is typically written in Swift today, loops primarily operate
on sequences and collections. It means that numerics is a domain that
not many people work in. But it is a very important domain
nevertheless, and clarity for numerics code matters at least as much
as it does everywhere else.

I think one way to approach this discussion would be to present
multiple concrete code samples that contain C-style for loops and are
awkward to write without them. We can then try looking for patterns,
generalize and simplify, and discuss possible solutions.

--
Greg Parker gparker@apple.com Runtime Wrangler


(Paul Ossenbruggen) #15

I guess I am not in the forloopian camp. I spend far too much time, converting for i = 0; i < 4; i++) into something more modern like iterating over containers. If it is in the language, people will use it, not having it there makes people think about better ways of doing things rather than relying on muscle memory. I know it is a barrier for some but other languages such as Python don’t support this construct and no one will deny that Python is heavily used in numerics.

- Paul

···

On Mar 19, 2016, at 1:28 AM, ted van gaalen via swift-evolution <swift-evolution@swift.org> wrote:

Yes, thank you Dmitri, I think so too.
Will come back to this later.
TedvG

ted van gaalen

On 19 Mar 2016, at 08:46, Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>> wrote:

Hi Ted,

Thank you for starting this thread. I agree that removing the C-style
for loop has degraded the readability and clarity of some of numerics
code.

In the feedback to SE-0007 many people have said that they can convert
their code to for-in loops, but I think this actually means that in
code that is typically written in Swift today, loops primarily operate
on sequences and collections. It means that numerics is a domain that
not many people work in. But it is a very important domain
nevertheless, and clarity for numerics code matters at least as much
as it does everywhere else.

I think one way to approach this discussion would be to present
multiple concrete code samples that contain C-style for loops and are
awkward to write without them. We can then try looking for patterns,
generalize and simplify, and discuss possible solutions.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com <mailto:gribozavr@gmail.com>>*/

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


(Patrick Gili) #16

I understand this. I am looking forward to see what Ted proposes.

-Patrick

···

On Mar 19, 2016, at 2:31 PM, Ross O'Brien <narrativium+swift@gmail.com> wrote:

But the discussion is no longer about 'do we really need to take this feature out?'. The feature is already out. It's deprecated in Swift 2.2. The discussion is 'is there a compelling reason to put it back in again?'.

We still have for-in loops. We still have repeat while. We still have forEach. Iteration isn't going anywhere; it just doesn't have this peculiar semi-colon structure any more. It's a confusing structure for beginning programmers to learn in the first place, and Swift doesn't use semi-colons so much.

On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:
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...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language brings them, for good or bad. If this group of people doesn't like a decision made by the community, they can grumble about it for awhile, suck in a deep breath, and move on.

2) Others; this group may be considering using Swift to develop software on other platforms and in other environments. If this group of people doesn't like a decision made by the community, they may think twice and it could significantly impact the uptake by this group of developers. I think it is wise that the community lubricate the transition to Swift as much as possible for this group of developers. I ask if leaving this kind of syntax in the language is so bad? Does it fall in the same category as removing function currying? My gut tells me not, but I could be wrong.

I also find it of the most importance to keep Swift accessible for all kinds of programmers
from starters to academic.

Graig Federighi said
We think it should be everywhere and used by everyone.

I subscribe to that.

-TedvG

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


(Charles Constant) #17

I know it is a barrier for some but other languages such as Python don’t

support this construct and no one will deny that Python is heavily used in
numerics.

I'd like to see a comparison, but Python "for" loops seem more flexible to
me than Swifts. It's been a couple years since I moved to Swift, but I
vaguely remember a lot of cool loop stuff in Python, like "for {} else" for
empty loops, etc.


(Charles Srstka) #18

The thing that I like about classical for loops is the ability to declare a variable for the iteration whose scope is limited to the loop. While you can replicate the functionality of a classical for loop with while, this requires declaring the variable outside of the scope of the loop.

Charles

···

On Mar 19, 2016, at 1:31 PM, Ross O'Brien via swift-evolution <swift-evolution@swift.org> wrote:

But the discussion is no longer about 'do we really need to take this feature out?'. The feature is already out. It's deprecated in Swift 2.2. The discussion is 'is there a compelling reason to put it back in again?'.

We still have for-in loops. We still have repeat while. We still have forEach. Iteration isn't going anywhere; it just doesn't have this peculiar semi-colon structure any more. It's a confusing structure for beginning programmers to learn in the first place, and Swift doesn't use semi-colons so much.

On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:

On Chris’s advice, I’ve spawned this into a new discussion topic, for which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:
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...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the language brings them, for good or bad. If this group of people doesn't like a decision made by the community, they can grumble about it for awhile, suck in a deep breath, and move on.

2) Others; this group may be considering using Swift to develop software on other platforms and in other environments. If this group of people doesn't like a decision made by the community, they may think twice and it could significantly impact the uptake by this group of developers. I think it is wise that the community lubricate the transition to Swift as much as possible for this group of developers. I ask if leaving this kind of syntax in the language is so bad? Does it fall in the same category as removing function currying? My gut tells me not, but I could be wrong.

I also find it of the most importance to keep Swift accessible for all kinds of programmers
from starters to academic.

Graig Federighi said
We think it should be everywhere and used by everyone.

I subscribe to that.

-TedvG

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

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


(Gavin Eadie) #19

Does this debate not arise from a common duality of purpose of the "for
(;;)" construct?
[in passing, and to acknowledge its longevity, I'll note I first saw this
"FOR .." years ago when learning FORTRAN]

--> Iterating Through the Members of a Collection .. Erica's proposal hits
this first usage nicely because, typically, the 'index' value is irrelevant
so why force its existence? I think everyone is happy that the old
construct is exorcised for this case.

--> Generating Values of a Variable Local to the Loop .. or the
"scientific, engineering, statistical, technical" use that Ted refers to.
In this case the "for (;;)" loop's purpose *is* the generation of the
'index' value, and the old construct does this more nicely than the new
[though I'll moderate my enthusiasm in a moment].

When you consider the total power of the "for (;;)" usage, several awesome,
and ghastly, things emerge. You'll think of more, but I think of using a
non-integer index; I think of compound statements before, after and between
the semi-colons; I think of the central conditional and the number of times
that I have fallen prey to an off-by-one error; I think of the final
'iteration' as being an arbitrary computation.

A simple example might be: for (altitude = 0.1; altitude < 10e6; altitude
=* 10.0) { . . . }

The two purposes I'm drawing out are not mutually exclusive, of course.
They're more like the ends of continuum of purposes, and each end can be
implemented (torturously?) by the others end's syntax. We've focused
attention on one end in SE-0007; now we need to do the same for the other
end. I look forward to Ted's suggestion for an elegant expression of
the "scientific,
engineering, statistical, technical" usage.

Finally, I'll note that when SE-0007 was being considered, I asked how I
might do the second case (I needed to span Doubles from X to Y in jumps of
Z. The best answer (of several), at that time, was:

    extension ClosedInterval where Bound: Strideable {

        func by(n: Bound.Stride) -> StrideThrough<Bound> {

            return start.stride(through: end, by: n)

        }

    }

and

    for angle in (X...Y).by(Z) { . . }

We can do better.

···

On Sat, Mar 19, 2016 at 2:58 PM, Patrick Gili via swift-evolution < swift-evolution@swift.org> wrote:

I understand this. I am looking forward to see what Ted proposes.

-Patrick

On Mar 19, 2016, at 2:31 PM, Ross O'Brien <narrativium+swift@gmail.com> > wrote:

But the discussion is no longer about 'do we really need to take this
feature out?'. The feature is already out. It's deprecated in Swift 2.2.
The discussion is 'is there a compelling reason to put it back in again?'.

We still have for-in loops. We still have repeat while. We still have
forEach. Iteration isn't going anywhere; it just doesn't have this peculiar
semi-colon structure any more. It's a confusing structure for beginning
programmers to learn in the first place, and Swift doesn't use semi-colons
so much.

On Sat, Mar 19, 2016 at 6:06 PM, Patrick Gili via swift-evolution < > swift-evolution@swift.org> wrote:

On Mar 18, 2016, at 7:19 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> >> wrote:

On Chris’s advice, I’ve spawned this into a new discussion topic, for
which the base could be
part of what I wrote in relation to SE-0007.

Hello Patrick
as I wrote:

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...

There are two groups of people to consider:

1) OS X and iOS developers; this group is stuck with whatever the
language brings them, for good or bad. If this group of people doesn't like
a decision made by the community, they can grumble about it for awhile,
suck in a deep breath, and move on.

2) Others; this group may be considering using Swift to develop software
on other platforms and in other environments. If this group of people
doesn't like a decision made by the community, they may think twice and it
could significantly impact the uptake by this group of developers. I think
it is wise that the community lubricate the transition to Swift as much as
possible for this group of developers. I ask if leaving this kind of syntax
in the language is so bad? Does it fall in the same category as removing
function currying? My gut tells me not, but I could be wrong.

I also find it of the most importance to keep Swift accessible for all
kinds of programmers
from starters to academic.

Graig Federighi said
*We think it should be everywhere and used by everyone.*

I subscribe to that.

-TedvG

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

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


(Gavin Eadie) #20

addendum: my example was discussed at

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151214/000488.html