[swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen]

Hi Austin, thank you, please see inline.
> On 28.07.2016, at 19:33, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> 
>> On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
? 
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!
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160728/f42d8b03/attachment.html>