Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS ++ and -- deprecated in swift
- Thread starter grandM
- Start date
- Sort by reaction score
I think that the thinking behind this is that x += 1 is more readable and x++ isn't particularly more concise. It also doesn't make sense to have a syntax for adding one to a variable, and a completely different syntax for adding any other number.
It also eliminates the confusion between pre and post increment (++x and x++).
I'm used to using x++, so in the short term it's a minor annoyance, but in the long term I think it's better to remove it, for the sake of clarity.
If you extend the argument in the other direction, adding x+++ to add two to a number certainly wouldn't make things more readable, and nor would x** to double a number. If you get used to it over time then it becomes an accepted part of the syntax and everybody understands it, but I don't think that's enough reason on its own to keep it around.
It also eliminates the confusion between pre and post increment (++x and x++).
I'm used to using x++, so in the short term it's a minor annoyance, but in the long term I think it's better to remove it, for the sake of clarity.
If you extend the argument in the other direction, adding x+++ to add two to a number certainly wouldn't make things more readable, and nor would x** to double a number. If you get used to it over time then it becomes an accepted part of the syntax and everybody understands it, but I don't think that's enough reason on its own to keep it around.
I did a quick search and couldn't find any official sources to back OP but if anyone could I'd love to read them.What is it being replace with? X = X +1
I don't see the logic of this, why would they end this, it's been a standard for years now. Can you cite a source?
Ok, looks like hogwash in the argument.
He says it's confusing to people learning the language. How about optionals? How about unwrapping.
He also says Swift already moved from C. That's no reason, C has been around forever and many learn it.
No benefit, it'll likely never fly.
He says it's confusing to people learning the language. How about optionals? How about unwrapping.
He also says Swift already moved from C. That's no reason, C has been around forever and many learn it.
No benefit, it'll likely never fly.
It's an added complexity that offers no benefit. Optionals are an added complexity that offer a significant benefit.
Admittedly it's not a difficult concept to understand, but complexity is complexity, and if you are a newcomer to the language, it's one more thing to learn - An extra page in the textbook, an extra lesson, an extra example project, and no additional capability gained.
I don't follow it too closely, but I think it's a done deal. The author of that proposal is Chris Lattner, who heads the Swift development, and it says accepted at the top.
Admittedly it's not a difficult concept to understand, but complexity is complexity, and if you are a newcomer to the language, it's one more thing to learn - An extra page in the textbook, an extra lesson, an extra example project, and no additional capability gained.
I don't follow it too closely, but I think it's a done deal. The author of that proposal is Chris Lattner, who heads the Swift development, and it says accepted at the top.
Really? Wow. I know it's a shorthand that can be done with X = X + 1, but it really doesn't seem that complex. Not to mention people coming from other languages.
At this point, thinking that someone would be a programmer and not know any other languages is simplistic. Few will learn Swift and only Swift. Even if they do just mobile, it's hard to ignore Android forever. ++ seems to be a programming standard that has to be one of the easy ones to learn.
However, Apple's languages tend to be verbose in many areas because they want readability, so maybe they will.
IMO, it's like using an acronym vs full words. How many people use acronyms vs writing things out?
The For-Next loops are going to look odd
Yep, it's been in the pipeline since before Swift went open source. I don't particularly care since those operators were messily integrated into Swift and therefore I seldom used them.
I hate to tell you this, but there's a proposal to depreciate that method of looping, too.
I hate to tell you this, but there's a proposal to depreciate that method of looping, too.
Wow, I can't even imagine what they'd replace the For-Next with.
Some people have too much time on their hands.
I got it out of this article. The article seemed to imply it was done. Checking its sources
it seems to be an accepted proposal. Not sure if this means it is implemented or not.
it seems to be an accepted proposal. Not sure if this means it is implemented or not.
Last edited:
It's happened as it is something that will be removed from Swift 3, when released. As of this moment, I would count it as depreciated even though we have a few months before the official rollover.
Last edited:
I've seen bugs from people confusing ++i and i++ inside expressions.
i += 1
isn't that much longer to type.
Interesting that they are not even offering it as backward compatible. For those that already wrote larger projects, they are forced to make these changes.
In addition, the gain (if any) of having something easier to learn, would be offset by the loss of having to unlearn and rewrite code.
It really make Swift look half baked when they change such a basic part of the language as a ++ or a for-next loop.
IMO, it really serves to make Swift look half-baked. It should make any IT dept rethink the stability of the code base going forward. Is the gain of this worth the loss of going back thru all the code and reworking it?
Didn't C++ and many OS's make an effort to be backward compatible?
In addition, the gain (if any) of having something easier to learn, would be offset by the loss of having to unlearn and rewrite code.
It really make Swift look half baked when they change such a basic part of the language as a ++ or a for-next loop.
IMO, it really serves to make Swift look half-baked. It should make any IT dept rethink the stability of the code base going forward. Is the gain of this worth the loss of going back thru all the code and reworking it?
Didn't C++ and many OS's make an effort to be backward compatible?
I pretty much agree with what was given in the github proposal with this one. While I can think of plenty of counter arguments, to say that it is rocking your entire core to have an minor operator removed like this is a little over dramatic to me. It's less abrasive than the optional syntax changes have been by a long run and even less abrasive than the depreciation of NSCalendarUnit's in iOS 7.
There are now benefits to using Swift over Objective-C that many IT departments will happily tolerate a single year cycle of major BC updates for. Those benefits are at the expense of backwards compatibility, and many people, not just Apple, feel those benefits are worth it. If they feel otherwise, then Objective-C is here to stay for a long while and it'll remain pretty static through the rest of its lifetime.
In the long run, you're going to need to revisit code anyway to ensure optimal performance and crashes when iOS 10 comes out in a few months, and taking spending some time revisiting and retooling an existing codebase, especially with major foundational changes, should be warranted anyway. The good news is that Swift updates have no chance of breaking your existing apps, iOS framework updates are a much more concerning front.
Anyway, to wig out over something you've used a minimal amount of time and will be automatically converted by the Swift migration tool when Swift 3 is released is blah. There have been far more frustrating changes in Swift in the past and potentially in the future, but in the long run they've been worth it in my book. Just gotta roll with the punches.
There are now benefits to using Swift over Objective-C that many IT departments will happily tolerate a single year cycle of major BC updates for. Those benefits are at the expense of backwards compatibility, and many people, not just Apple, feel those benefits are worth it. If they feel otherwise, then Objective-C is here to stay for a long while and it'll remain pretty static through the rest of its lifetime.
In the long run, you're going to need to revisit code anyway to ensure optimal performance and crashes when iOS 10 comes out in a few months, and taking spending some time revisiting and retooling an existing codebase, especially with major foundational changes, should be warranted anyway. The good news is that Swift updates have no chance of breaking your existing apps, iOS framework updates are a much more concerning front.
Anyway, to wig out over something you've used a minimal amount of time and will be automatically converted by the Swift migration tool when Swift 3 is released is blah. There have been far more frustrating changes in Swift in the past and potentially in the future, but in the long run they've been worth it in my book. Just gotta roll with the punches.
I don't mind rolling with the punches, but I'm having trouble seeing the gain. Some things take a bit to really understand. Optionals take a bit more to understand vs removing the ";".
Given that a programmer will likely need to know several languages, you still have the issue of someone knowing Java or C++ and having to switch over to a different mind set for Swift.
I can see the advantage of a new language that is made for mobile development, but pulling working code from one language to another just became more of a job.
The argument about programmers screwing up a ++ usage, would still happen in other languages.
I worked in a shop that had a couple of different languages used and it sucked for productivity. We had to hire different people with different skill sets and once you have a large code base, you have to find experts in that language.
I wonder how many companies will just say no and go with a 3rd party product that works across all platforms.
I wonder how many game developers will pass on Swift and just do everything in Unity. I don't see Swift having any advantage at all in game development compared to Unity, although I'm not into game development.
Given that a programmer will likely need to know several languages, you still have the issue of someone knowing Java or C++ and having to switch over to a different mind set for Swift.
I can see the advantage of a new language that is made for mobile development, but pulling working code from one language to another just became more of a job.
The argument about programmers screwing up a ++ usage, would still happen in other languages.
I worked in a shop that had a couple of different languages used and it sucked for productivity. We had to hire different people with different skill sets and once you have a large code base, you have to find experts in that language.
I wonder how many companies will just say no and go with a 3rd party product that works across all platforms.
I wonder how many game developers will pass on Swift and just do everything in Unity. I don't see Swift having any advantage at all in game development compared to Unity, although I'm not into game development.
I'm not sure I 'get' the point of Swift yet. Every couple of months I have a bit of a play and come across things I like and things which just drive me nuts. I really like the '++' style operations. I find them elegant.
I'm just not buying the argument that ++ is difficult to learn. Seriously, as a carrier programmer you will have to understand much more difficult concepts. I don't agree that swift is this easy to learn language either, it is very easy to shoot yourself in the foot unless you are careful.
I'm sure Swift will be super successful but it is still a long way away from me using it full time. And these silly things are just pushing the boat out further.
I'm just not buying the argument that ++ is difficult to learn. Seriously, as a carrier programmer you will have to understand much more difficult concepts. I don't agree that swift is this easy to learn language either, it is very easy to shoot yourself in the foot unless you are careful.
I'm sure Swift will be super successful but it is still a long way away from me using it full time. And these silly things are just pushing the boat out further.
I can somehwat understand removing the ++ and -- operators though I used them on a daily basis.
But removing C style for loops is just plain stupid. Seriously, it's just dumb. There's no reason to remove them.
That would only serve to dumb down the language, really.
But removing C style for loops is just plain stupid. Seriously, it's just dumb. There's no reason to remove them.
That would only serve to dumb down the language, really.
Python has never had ++ or --. When you have a foreach operator with extensive support, there's little reason to have those operators.
Most people who move from one language to Python never realize those operators don't exist.
If you ever do what to do that, you write +=1 or -=1. One extra character (or 3 extra with proper spacing). Not a big deal.
Most people who move from one language to Python never realize those operators don't exist.
If you ever do what to do that, you write +=1 or -=1. One extra character (or 3 extra with proper spacing). Not a big deal.
If games are one of the main categories of app dev, Swift is really missing the mark on this. Aren't most game written in C#/C++ or Java? Wouldn't anyone coming from a game dev platform know some version of these?
Swift moving from these mainstream languages is not going to make Swift easier to learn for these people. It's likely to move people over to Unity or some other 3rd party platform.
Making it harder to move code from ObjC to Swift because they read differently isn't going to help either.
Swift moving from these mainstream languages is not going to make Swift easier to learn for these people. It's likely to move people over to Unity or some other 3rd party platform.
Making it harder to move code from ObjC to Swift because they read differently isn't going to help either.
Allowing Swift to deviate from Objective-C is the entire point of its existence. If they weren't willing make major changes, they would have just continued with Objective-C. If they made these changes out the gate, it would have justified the conversations here (plus probably pushed back Swift's release time) by making the intoduction seem too removed from what we know already with Objective-C.
But it's been >2 years and unless you've had your head under a rock, most iOS developers are familiar with both languages. It's time to take the common ground and use it as a stepping stone to features they want in the language. It's easy to focus on a small change and blow it up as a foundational ideal change, but in the grand scheme, but it isn't telling anything different than what Swift has for the past few iterations.
But it's been >2 years and unless you've had your head under a rock, most iOS developers are familiar with both languages. It's time to take the common ground and use it as a stepping stone to features they want in the language. It's easy to focus on a small change and blow it up as a foundational ideal change, but in the grand scheme, but it isn't telling anything different than what Swift has for the past few iterations.
I do like the idea of removing ++/-- and For-Next loops. The former make any sense only when the latter is used, otherwise += 1 is way better.
The removal of For-Next loops will force people to use foreach loops when they are available and I believe this will lead to more readable and less error prone code.
The main reason to use a for-next loop is when you need to loop through a container while retaining indices. In my opinion writing
for i in array.indices {}
is much better than
for (let i = 0; i < array.count; i++) {}
For one this means that if the container changes and the indices are not contiguous you can still use it. For more complicated cases a while loop is better. For fixed amount of loops for i in 1...5 is better, I could go on.
For me, this change will lead to better and more readable code and will move us one step closer towards a definition of an idiomatic swift.
The removal of For-Next loops will force people to use foreach loops when they are available and I believe this will lead to more readable and less error prone code.
The main reason to use a for-next loop is when you need to loop through a container while retaining indices. In my opinion writing
for i in array.indices {}
is much better than
for (let i = 0; i < array.count; i++) {}
For one this means that if the container changes and the indices are not contiguous you can still use it. For more complicated cases a while loop is better. For fixed amount of loops for i in 1...5 is better, I could go on.
For me, this change will lead to better and more readable code and will move us one step closer towards a definition of an idiomatic swift.