> On 5 Dec 2015, at 10:26, Matthijs Hollemans <m...@hollance.com> wrote: > > The proposal for the removal of the ++ and -- operators states that, > >> In terms of roll-out, we should deprecate them in the Spring Swift 2.x >> release (with a nice Fixit hint to cover common cases), and remove them >> completely in Swift 3. > > Is it possible to keep the Spring 2.x release non-breaking and backwards > compatible? Authors of books everywhere will be grateful. :-) > > With the speed that Swift is moving, books are out-of-date before they even > hit the shelves. Doing a major yearly update is manageable (barely) but more > than that is a huge burden. > > Most importantly, it is not a very nice experience for readers if the book > they just bought is now wrong. The last thing you want to see as a beginner > is warnings or error messages on code that you’ve just typed in from a book. > > Now that the evolution of Swift is a community effort, it would be nice if > the contribution of book and tutorial authors to the popularity of Swift is > recognized and appreciated by the Swift team, and their concerns taken into > account as well.
Yes, it's certainly a challenge I have seen. However the openness of future changes is definitely advantageous (including beta releases) since it allows a first draft to be written and then hopefully not too much changes between then and the final release. The same problem also exists in StackOverflow answers where users have accepted a question that no longer works. It's almost impossible to go through the list of UIKit questions where an "as UIxxx" needs to be changed to an "as! UIxxx" but it might be more practical to work through those that have ++ or -- in them - provided that you can search questions for symbols which I'm not sure you always can. The point is that language agility is good in the initial few releases but each subsequent change has the potential to cause more of the tutorial/how to/blog posts to atrophy, and this should generally be a concern taken into account when changing or removing any feature. Alex _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
