Roll-out of deprecating ++ and --


(Matthijs Hollemans) #1

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

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鈥檝e 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


(Chris Lattner) #2

Yes, that is the general goal. I doubt that Swift 2.2 will be 100% compatible with Swift 2.1, but we don鈥檛 want major breaking changes. Things like removal of ++, wide-spread renaming of stdlib and Cocoa APIs (etc) shouldn鈥檛 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. :-)


(Alex Blewitt) #3

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

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鈥檝e 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.


(Rudolf Adamkovi膷) #4

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

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鈥檝e 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


(Matthijs Hollemans) #5

Awesome, thanks for clarifying. :slight_smile:

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

Yes, that is the general goal. I doubt that Swift 2.2 will be 100% compatible with Swift 2.1, but we don鈥檛 want major breaking changes. Things like removal of ++, wide-spread renaming of stdlib and Cocoa APIs (etc) shouldn鈥檛 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