End of source-breaking changes for Swift 3


(Ted van Gaalen) #1

Hi Ted !

Thanks guys for all for the hard work!
What you wrote makes sense, is a relief, and gives me faith in Swift’s future!

The Swift team at Apple has reflected on this and decided what it "means" for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.

This sounds like a reasonable solution...
If I understand you correctly;
   The compiler(s) would be able to compile sources from 3.0 and future versions?

well, that solves most source breaking issues,

It then has however the disadvantage that one cannot
combine older language elements from
e.g. version 3.0 and 4.0 or higher together in a single source file?
However, if so, I can live with that.

Does this method have further compatibility issues that at the moment don’t cross my mind?

Unfortunately that doesn’t go back to 2.2, unfortunately
because in 3.0 the classical for ; ; loop will be deactivated.

I regard this as a serious mistake and
have no doubt this removal is disturbing many
experienced and more pragmatical programmers.

It made my alarm bells ringing and it was the main
reason I have climbed in to Swift-Evolution
to discuss this.

      -= Maybe it’s not too late =-
For the moment the classical for ;; could simply
remain activated (Yes) in 3.0. because:
  
  - It doesn’t conflict at all with all other language elements,

  - most important: there are still no good alternative for iterations like these
       for var x:Float = -60; x < 60; x += w * 1.2
       {
           for var y: Float = 130; y > 60; y -= backtrack
          // etc.
          // especially for iterations using Floating point numbers!

         for these, one has to fall back on tedious do-while constructs.

  - There are more sane reasons, but a few months ago
     I have written extensively about this subject.

So, yes, obviously my recommendation is

Please don’t remove the for ;; from 3.0

and replace the current compile cry:
    “C-style for statement is deprecated and will be removed in a future version of Swift”

which I currently perceive like this:

   “ The for ;; statement, although being used successfully in many other languages
      is in conflict with the attitude and believe of some of us with a lot of theoretical experience.
     Therefore it will be removed in a future version of Swift.
     Please resort to using the do-while statement instead.”

the new compiler warning could be then:
  “Warning! This for ;; statement should only be used by highly skilled
   programmers with a more pragmatical attitude.
   Use at your own risk, like with any other Swift statement.”

Just leave it in. (but I guess it could be to late)

If it is really removed in 3.0, then I promise I will write
an official proposal to bring it back in 3.x and further.
some help with that is appreciated.

Kind Regards

Yet another Ted :o)

www.tedvg.com

Date: Wed, 27 Jul 2016 12:38:51 -0700
From: Ted Kremenek <kremenek@apple.com <mailto:kremenek@apple.com>>
To: swift-evolution@swift.org <mailto:swift-evolution@swift.org>, swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>,
  swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>>
Subject: [swift-evolution] End of source-breaking changes for Swift 3

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are.

<snip>

···

Thank you again to everyone for making Swift 3 such as fantastic release!

Ted


(Austin Zheng) #2

      -= Maybe it’s not too late =-
For the moment the classical for ;; could simply
remain activated (Yes) in 3.0. because:

I don't understand why you keep on complaining about this.

For the record, I too think getting rid of the C-style for loop was a mistake, and there are a number of other proposals whose outcomes are not ones I would have personally preferred.

However,

1. There is a well-defined process through which all changes to the Swift language must go, laid out in the swift-evolution repository's documentation from the first day Swift became an open-source project.
2. That process includes feedback and review from both the community and the Swift core engineers, and often multiple rounds of discussion.
3. The process doesn't work if we disregard its outcomes simply because we don't like them, or if we allow interminable chains of back-and-forth proposals because people on one side of issue X simply cannot accept a particular decision.

The technical aspects of the C-style for loop and its proposed replacements have already been discussed ad nauseam on this list and in other places, so I won't touch on them.

Best regards,
Austin

···

On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

  - It doesn’t conflict at all with all other language elements,


(Chris Lattner) #3

The Swift team at Apple has reflected on this and decided what it "means" for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.

This sounds like a reasonable solution...
If I understand you correctly;
   The compiler(s) would be able to compile sources from 3.0 and future versions?

Correct.

Unfortunately that doesn’t go back to 2.2,

Correct - this doesn’t apply to Swift 2.2 or Swift 2.3. Source compatibility will start with Swift 3, just like we’ve been saying for some time now.

-Chris

···

On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:


(Ted van Gaalen) #4

Hi Austin, thank you, please see inline.

      -= Maybe it’s not too late =-
For the moment the classical for ;; could simply
remain activated (Yes) in 3.0. because:

I don't understand why you keep on complaining about this.

?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

For example the suggestion, that experienced
programmer will refrain from using the for;;
was ridiculous. It’s a bit like assuming that a technicians
will not use a screw drivers anymore..

I’ve wrote about this extensively before.

Just read that proposal to remove
the for;; and for that matter also the ++ and — again..
Albeit a bit understandable: It was one of the first proposals,
written in a time when everything had just started..

Personally, for my apps, removing the for;; results in lots of
otherwise unnecessary time converting at least ten source files,
typically containing about five for;; loops each, nested ones also.

Automagic conversion is not possible also because many of
these iterations are with floating point numbers and also
run backwards.let alone with decrementing steps.

In my Apple TV 3D SceneKit based app under construction
these are for;; with floats, which have to be replaced by do-while constructs..

In all of my apps (i am a pour lonesome developer :o)
I have to test all of this again and again to make sure
my apps work flawlessly without errors again, as they do now.
(see RavelNotes and RavelNotesBasic)
These apps are quite complex, changing and testing
these is not that easy.

Ergo: as a law of steel:
One should *never* introduce backward breaking changes!

So I am very glad Ted Kremenek came forward with this
module based different version compilation option.
It seems to be a reasonable alternative.

If not, I would have dropped Swift soon and look for another
solution to produce my apps. However, this would be very regrettable.
because I really love Swift. I wouldn’t be here if I didn’t !

I was quite happy with Swift 2. It had all the things I tend to expect
from a state of the art programming language. very cool.
and also eagerly waiting for *additive* changes and improvements.

@Craig:
When Swift was presented and its use encouraged by you, Craig, on the WWDC,
it was not supposed to be in a *beta stage* ! At least, it was my impression
that it was no longer in beta stage and that it was OK to use Swift for
production, no one told otherwise, if I remember correctly.

And so I embraced Swift immediately, me being mostly an early adapter
  (even when being in IT since 1978 or so, or maybe rather because of that!)
assuming that it was solid and a safe bet to use it in a production environment.

However, IMHO, it has been virtually in a beta stage until now,
simply because, things were and are still changing!.
Yes, of course I do expect improvements, however they should be
additive, not code breaking changes.

I also do understand and don’t underestimate the motion with new languages.

If I had known all this before, I would have remained programming
my apps in Objective C until a more solid version came along.
In the mean time, yes, of course, I would have played with it and studying it
sideways, and take part and listening in this forum.

And, maybe then I would have enough faith in 3.0 that is to
use Swift 3.0 and higher fully in a production environment.
And don’t get me wrong, I like Swift very much it really
is a very advanced development.

And then another thing, well, maybe you’d
think that I am whining a bit, but try to see it this way:
Most things in Swift are OK and even superb, so I don’t
need to write about these! What remains then is just to
write about the thing’s I don’t like or which could be
improved. This might give the impression that I am just
complaining, note however, nothing is farther from the truth.

( because we just write, which is a very limited form
of human communication being a lot different then sitting
around a round table (hmm that reminds me of something :o)
laughing and drinking coffee. I you’d wish to change that
send me a ticket to San Francisco or so. :o)

For the record, I too think getting rid of the C-style for loop was a mistake,

Yes it is. Well, then maybe you also could perhaps have made more effort
to keep the for;; and other colleagues too that think likewise?
Or in the near future, to support my upcoming proposal?

and there are a number of other proposals whose outcomes are not ones I would have personally preferred.

Of course, I realize that as well, that goes for me too.
https://www.youtube.com/watch?v=7S94ohyErSw
:o)

However,

1. There is a well-defined process through which all changes to the Swift language must go, laid out in the swift-evolution repository's documentation from the first day Swift became an open-source project.

I know that, and that’s why I will make a proposal after 3.0 to reinstate the classical for loop.

2. That process includes feedback and review from both the community and the Swift core engineers, and often multiple rounds of discussion.

Agreed, but I arrived much later..

3. The process doesn't work if we disregard its outcomes simply because we don't like them, or if we allow interminable chains of back-and-forth proposals because people on one side of issue X simply cannot accept a particular decision.

Obviously, however, if a proposal, due to later insights, is wrong or conflicting is should be discussable to drop, correct or replace it.

The technical aspects of the C-style for loop and its proposed replacements have already been discussed ad nauseam on this list and in other places, so I won't touch on them.

true, I’ve had my share in these too. what remains now for me to do is,
to propose a reinstatement of the for ;; (as in Go) after 3.0
I’ll do that.

Met vriendelijke groeten
from a Dutch professional somehow landed in Germany :o)
TedvG
www.tedvg.com <http://www.tedvg.com/>
www.ravelnotes.com <http://www.ravelnotes.com/>
www.speyer.de <http://www.speyer.de/>

Best regards,
Austin

  - It doesn’t conflict at all with all other language elements,

YEs!

···

On 28.07.2016, at 19:33, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:


(Ted van Gaalen) #5

Thanks, Chris.

···

On 28.07.2016, at 22:56, Chris Lattner <clattner@apple.com> wrote:

On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

The Swift team at Apple has reflected on this and decided what it "means" for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.

This sounds like a reasonable solution...
If I understand you correctly;
  The compiler(s) would be able to compile sources from 3.0 and future versions?

Correct.

Unfortunately that doesn’t go back to 2.2,

Correct - this doesn’t apply to Swift 2.2 or Swift 2.3. Source compatibility will start with Swift 3, just like we’ve been saying for some time now.

-Chris


(Austin Zheng) #6

Hi Austin, thank you, please see inline
?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

I don't care how good your reasons are, the fact of the matter is that it
was extensively discussed, a decision was made, and it is now a done deal.
Please remember that these are high-traffic lists that many people
subscribe to; complaining about the C for loop is a waste of everybody's
time. At the very least, please respect the process and put together a
proposal that we can all discuss, instead of asking Chris or whoever to
step in and make an exception because you don't like it.

Austin

···

On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com> wrote:

For example the suggestion, that experienced
programmer will refrain from using the for;;
was ridiculous. It’s a bit like assuming that a technicians
will not use a screw drivers anymore..

I’ve wrote about this extensively before.


(Karl) #7

+1. There have been lots of accepted proposals which I argued against, but community-driven evolution means we have to compromise.
  
In Plato's Crito, Socrates refuses to flee Athens after being sentenced to death. He entered in to an agreement with the state to participate in the process and respect its judgements, and reasons that to violate the rules of the system because he believes the outcome unjust would be a greater injustice.
  
Just mentioning it; it's always been a fascinating story to me.
  
Karl

···

Sent from my new Email (https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email)
  

On Jul 28, 2016 at 7:33 PM, <Austin Zheng via swift-evolution (mailto:swift-evolution@swift.org)> wrote:
  
>
> On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org (mailto:swift-evolution@swift.org)> wrote:
>
>
>
>
>
> -= Maybe it’s not too late =-
>
> For the moment the classical for ;; could simply
>
> remain activated (Yes) in 3.0. because:
>
>
>
  
I don't understand why you keep on complaining about this.
  
For the record, I too think getting rid of the C-style for loop was a mistake, and there are a number of other proposals whose outcomes are not ones I would have personally preferred.
  
However,
  
1. There is a well-defined process through which all changes to the Swift language must go, laid out in the swift-evolution repository's documentation from the first day Swift became an open-source project.
  
2. That process includes feedback and review from both the community and the Swift core engineers, and often multiple rounds of discussion.
  
3. The process doesn't work if we disregard its outcomes simply because we don't like them, or if we allow interminable chains of back-and-forth proposals because people on one side of issue X simply cannot accept a particular decision.
  
The technical aspects of the C-style for loop and its proposed replacements have already been discussed ad nauseam on this list and in other places, so I won't touch on them.
  
Best regards,
  
Austin
  
>
>
>
>
>
> - It doesn’t conflict at all with all other language elements,
>
>
>
  
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org (mailto:swift-evolution@swift.org) https://lists.swift.org/mailman/listinfo/swift-evolution


(Ted van Gaalen) #8

Hi Austin,

please read inline.

Hi Austin, thank you, please see inline
?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

I don't care how good your reasons are, the fact of the matter is that it was extensively discussed, a decision was made, and it is now a done deal.

Napoleon said something similar when pushing his army towards Moscow...

Please remember that these are high-traffic lists that many people subscribe to; complaining about the C for loop is a waste of everybody's time.

That’s your opinion.

At the very least, please respect the process and put together a proposal that we can all discuss,

As written before, I will write the proposal after Swift 3.0 is released.
If you are interested in bringing it back then you could help
me with it.

instead of asking Chris or whoever to step in and make an exception because you don't like it.

Yes, indeed, I am exceptionally asking to make an exception, to keep the for ;; in
for the time being.

As concerning your “high traffic” notion, this is written material
no doubt, the recipients are capable enough to put it aside for later
if they’d wish to do so.

Sorry, if you don’t like it.
Thanks.
TedvG

···

On 28.07.2016, at 23:47, Austin Zheng <austinzheng@gmail.com> wrote:
On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:


(Garth Snyder) #9

Karl Wagner: In Plato's Crito, Socrates refuses to flee Athens after being sentenced to death. He entered in to an agreement with the state to participate in the process and respect its judgements, and reasons that to violate the rules of the system because he believes the outcome unjust would be a greater injustice.

All right, then — hemlock for the lot of you… :slight_smile:

Garth


(Saagar Jha) #10

The reason C-style for loops were removed were because most of the time they could be represented by Swift syntax. Have you taken a look at stride(from:to:by:)?

Saagar Jha

···

On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org> wrote:

Hi Austin,

please read inline.

On 28.07.2016, at 23:47, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
Hi Austin, thank you, please see inline
?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

I don't care how good your reasons are, the fact of the matter is that it was extensively discussed, a decision was made, and it is now a done deal.

Napoleon said something similar when pushing his army towards Moscow...

Please remember that these are high-traffic lists that many people subscribe to; complaining about the C for loop is a waste of everybody's time.

That’s your opinion.

At the very least, please respect the process and put together a proposal that we can all discuss,

As written before, I will write the proposal after Swift 3.0 is released.
If you are interested in bringing it back then you could help
me with it.

instead of asking Chris or whoever to step in and make an exception because you don't like it.

Yes, indeed, I am exceptionally asking to make an exception, to keep the for ;; in
for the time being.

As concerning your “high traffic” notion, this is written material
no doubt, the recipients are capable enough to put it aside for later
if they’d wish to do so.

Sorry, if you don’t like it.
Thanks.
TedvG

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


(Ted van Gaalen) #11

+1. There have been lots of accepted proposals which I argued against, but community-driven evolution means we have to compromise.

This would imply, that if a decision is made, which in a later and changed context proves to be a bad one, would be irreversible?
Better turn half way than to err in continuing.
Or, one decides to go diving, but arriving at the location, notice that the water is full of sharks? Still continue?

In Plato's Crito, Socrates refuses to flee Athens after being sentenced to death. He entered in to an agreement with the state to participate in the process and respect its judgements, and reasons that to violate the rules of the system because he believes the outcome unjust would be a greater injustice.

Just mentioning it; it's always been a fascinating story to me.

Thanks, interesting. Long ago I’ve read a bit in Plato - The Republic but was back then
to hyper active to concentrate..

Karl

Sent from my new Email <https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=my_new_email>

TedvG

···

On 28.07.2016, at 20:20, Karl Wagner <razielim@gmail.com> wrote:

On Jul 28, 2016 at 7:33 PM, <Austin Zheng via swift-evolution <mailto:swift-evolution@swift.org>> wrote:

On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

      -= Maybe it’s not too late =-
For the moment the classical for ;; could simply
remain activated (Yes) in 3.0. because:

I don't understand why you keep on complaining about this.

For the record, I too think getting rid of the C-style for loop was a mistake, and there are a number of other proposals whose outcomes are not ones I would have personally preferred.

However,

1. There is a well-defined process through which all changes to the Swift language must go, laid out in the swift-evolution repository's documentation from the first day Swift became an open-source project.
2. That process includes feedback and review from both the community and the Swift core engineers, and often multiple rounds of discussion.
3. The process doesn't work if we disregard its outcomes simply because we don't like them, or if we allow interminable chains of back-and-forth proposals because people on one side of issue X simply cannot accept a particular decision.

The technical aspects of the C-style for loop and its proposed replacements have already been discussed ad nauseam on this list and in other places, so I won't touch on them.

Best regards,
Austin

  - It doesn’t conflict at all with all other language elements,

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


(Taras Zakharko) #12

The reason C-style for loops were removed were because most of the time they could be represented by Swift syntax. Have you taken a look at stride(from:to:by:)?

A minor correction: it should be ‚all of the time‘ :slight_smile: Iterator-based loops are a strict superset of the for(;:wink: loop.

Anyway, we have discussed this extensively in the past, Ted is the only person who’s still keeps stubbornly hacking on this topic and so far he has failed to produce any convincing evidence in favour of the for(;:wink: loop. Its time to either accept defeat or produce some new material to discuss. Austin is absolutely right that repeating same things only makes this already huge list even bigger and less digestible.

Best,

T.

···

On 29 Jul 2016, at 00:21, Saagar Jha via swift-evolution <swift-evolution@swift.org> wrote:

Saagar Jha

On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Austin,

please read inline.

On 28.07.2016, at 23:47, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
Hi Austin, thank you, please see inline
?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

I don't care how good your reasons are, the fact of the matter is that it was extensively discussed, a decision was made, and it is now a done deal.

Napoleon said something similar when pushing his army towards Moscow...

Please remember that these are high-traffic lists that many people subscribe to; complaining about the C for loop is a waste of everybody's time.

That’s your opinion.

At the very least, please respect the process and put together a proposal that we can all discuss,

As written before, I will write the proposal after Swift 3.0 is released.
If you are interested in bringing it back then you could help
me with it.

instead of asking Chris or whoever to step in and make an exception because you don't like it.

Yes, indeed, I am exceptionally asking to make an exception, to keep the for ;; in
for the time being.

As concerning your “high traffic” notion, this is written material
no doubt, the recipients are capable enough to put it aside for later
if they’d wish to do so.

Sorry, if you don’t like it.
Thanks.
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


(Ross O'Brien) #13

This would imply, that if a decision is made, which in a later and changed
context proves to be a bad one, would be irreversible?
Better turn half way than to err in continuing.
Or, one decides to go diving, but arriving at the location, notice that
the water is full of sharks? Still continue?

But there's no 'continue' here. The time to 'turn half way' was months ago.
We already arrived.

We moved house. We sold the old one, handed over the keys, moved into the
new place and put up the wallpaper. If you want to move back to the old
house, you'll need to convince everyone to put everything back into boxes.

Swift 3 does not have C-style for-loops. That decision has been made.

But on August 1, feel free to make a pitch explaining why C-style for-loops
are a feature worth adding to Swift 4.


(Ted van Gaalen) #14

Hi Ross,

This would imply, that if a decision is made, which in a later and changed context proves to be a bad one, would be irreversible?
Better turn half way than to err in continuing.
Or, one decides to go diving, but arriving at the location, notice that the water is full of sharks? Still continue?

But there's no 'continue' here. The time to 'turn half way' was months ago. We already arrived.

We moved house. We sold the old one, handed over the keys, moved into the new place and put up the wallpaper. If you want to move back to the old house, you'll need to convince everyone to put everything back into boxes.

Hey Ross, look around you in the house! Ah, there it is!
You’d only have to unpack the box with the for;; it’s still there :o)
I bet, the components in the compiler to process a for;; are still present in the 3.0 compiler
and could be simply reactivated?

Swift 3 does not have C-style for-loops. That decision has been made.

But on August 1, feel free to make a pitch explaining why C-style for-loops are a feature worth adding to Swift 4.

Will do. thanks.

Anyway:
I’ll drop the subject for now, also
because my highly exceptional request will probably not be honored.
Then so be it.
Met vriendelijke groeten
Ted

···

On 29.07.2016, at 00:21, Ross O'Brien <narrativium+swift@gmail.com> wrote:


(Ted van Gaalen) #15

Hi Taras,

There’s more than enough evidence in the whole programming world
to justify the existence of the classical for loop, also in Swift!
Not only in “old” languages, for instance, take a look in Go.
Excellent implementation there of the for;;

https://tour.golang.org/flowcontrol/1

Btw, to me, It’s not a matter of “defeat” or “winning”.

I am not the only person preferring the for;; to stay.

I’ve also written about other things, like comma less parameter list etc.

But I will not continue this discussion right now and wait til August.

Kind Regards
TedvG

The reason C-style for loops were removed were because most of the time they could be represented by Swift syntax. Have you taken a look at stride(from:to:by:)?

Yes I did.

A minor correction: it should be ‚all of the time‘ :slight_smile: Iterator-based loops are a strict superset of the for(;:wink: loop.

No. the for;; is much more versatile and easier to use, but I’v already wrote much about this.

Anyway, we have discussed this extensively in the past, Ted is the only person who’s still keeps stubbornly hacking on this topic and so far he has failed to produce any convincing evidence in favour of the for(;:wink: loop.

Please read it again.

···

On 29.07.2016, at 00:30, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

On 29 Jul 2016, at 00:21, Saagar Jha via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Its time to either accept defeat or produce some new material to discuss. Austin is absolutely right that repeating same things only makes this already huge list even bigger and less digestible.

Best,

T.

Saagar Jha

On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Austin,

please read inline.

On 28.07.2016, at 23:47, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen <tedvgiosdev@gmail.com <mailto:tedvgiosdev@gmail.com>> wrote:
Hi Austin, thank you, please see inline
?
I have explained this many times before, didn’t I?

Its removal causes a very crucial limitation/change in the way
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

I don't care how good your reasons are, the fact of the matter is that it was extensively discussed, a decision was made, and it is now a done deal.

Napoleon said something similar when pushing his army towards Moscow...

Please remember that these are high-traffic lists that many people subscribe to; complaining about the C for loop is a waste of everybody's time.

That’s your opinion.

At the very least, please respect the process and put together a proposal that we can all discuss,

As written before, I will write the proposal after Swift 3.0 is released.
If you are interested in bringing it back then you could help
me with it.

instead of asking Chris or whoever to step in and make an exception because you don't like it.

Yes, indeed, I am exceptionally asking to make an exception, to keep the for ;; in
for the time being.

As concerning your “high traffic” notion, this is written material
no doubt, the recipients are capable enough to put it aside for later
if they’d wish to do so.

Sorry, if you don’t like it.
Thanks.
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution