Roll-out of deprecating ++ and --

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.

Thanks!

-Matthijs

1 Like

Yes, that is the general goal. I doubt that Swift 2.2 will be 100% compatible with Swift 2.1, but we don’t want major breaking changes. Things like removal of ++, wide-spread renaming of stdlib and Cocoa APIs (etc) shouldn’t go into Swift 2.2, they should wait for Swift 3. That said, making these things *warnings* in Swift 2.2 is desirable, because that makes the transition path to swift 3 smoother.

-Chris

···

On Dec 5, 2015, at 1:26 AM, Matthijs Hollemans <mail@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. :-)

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

···

On 5 Dec 2015, at 10:26, Matthijs Hollemans <mail@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.

-1

Slowing down development so that paper books can keep up? Sounds like a very bad idea to me.

R+

···

Sent from my iPhone

On 05 Dec 2015, at 10:26, Matthijs Hollemans <mail@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.

Thanks!

-Matthijs

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

Awesome, thanks for clarifying. :-)

-Matthijs

···

On 5 dec. 2015, at 18:29, Chris Lattner <clattner@apple.com> wrote:

On Dec 5, 2015, at 1:26 AM, Matthijs Hollemans <mail@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. :-)

Yes, that is the general goal. I doubt that Swift 2.2 will be 100% compatible with Swift 2.1, but we don’t want major breaking changes. Things like removal of ++, wide-spread renaming of stdlib and Cocoa APIs (etc) shouldn’t go into Swift 2.2, they should wait for Swift 3. That said, making these things *warnings* in Swift 2.2 is desirable, because that makes the transition path to swift 3 smoother.

-Chris