Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming Apple

Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3' (infoworld.com) 148

Posted by EditorDavid from the think-different dept.
An anonymous Slashdot reader quotes InfoWorld: "Move fast and break things," the saying goes. Apple does both with the 3.0 version of its Swift programming language...its first full point revision since it became an open source project... In a blog post detailing the full body of changes for Swift 3.0, Apple singled out the two biggest breaking changes. The first is better translation of Objective-C APIs into Swift, meaning that code imported from Objective-C and translated into Swift will be more readable and Swift-like. The bad news is any code previously imported from Objective-C into Swift will not work in Swift 3; it will need to be re-imported.

The other major change... Most every item referenced in the standard library has been renamed to be less wordy. But again, this brings bad news for anyone with an existing Swift codebase: Apple says "the proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code."
Apple will provide migration tools in version 8.0 of their XCode IDE, "but such tools go only so far," notes the article, questioning what will happen to the Linux and Windows ports of Swift.
This discussion has been archived. No new comments can be posted.

Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3' More

Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3'

Comments Filter:

  • better now (Score:5, Insightful)

    by goombah99 ( 560566 ) on Sunday September 18, 2016 @10:49PM (#52914949)

    than later when there's a huge code base.

    • Maybe, but they had enough time until 2.3 to get things right, to ensure compatibility, at least.

    • That's the attitude behind the last 12 different Microsoft phone platform reboots!

    • No. Better never make code breaking changes. You have all the time in the world to make API changes before it becomes public, then it remains fixed.
      Paticularly, trivial name changes are bad. It doesn't really matter if the function is called "sort" or "sorted" if you are breaking old code that's bad.

  • Breathes new life into old APIs (Score:5, Informative)

    by SuperKendall ( 25149 ) on Sunday September 18, 2016 @10:50PM (#52914953)

    I have a pretty decent amount of Swift and the change between this version and previous versions is a lot more to absorb than it has been in the past... the migrator tool does help though it seems like it doesn't do as much as it could (that may have changed from earlier betas though).

    However, whatever brief pain this brings upon us, is more than made up by the improvements Swift3 brings to the Cocoa API...

    Have you ever worked on an Api for a long time, and thought "if I could do this again I'd rename all this stuff, and structure this one thing differently..."

    Well that's one thing Swift3 did for Cocoa - there's basically a whole new name mapping overlay for Cocoa that makes lots and lots of calls much clearer, and also extensions that offer more Swift friendly API calls in some cases.

    And the nice thing is some of the mappings are algorithmic, so your own ObjectiveC code you call from Swift benefits from name tidying or simplification, which works out well because of naming conventions Cocoa has long had and almost all Cocoa programmers follow.

    There are also specially tweaked mappings to some parts where special cases made the automatic mapping not make sense, so it's like the whole API has had an overview and some re-thought applied.

    It is sad that Swift3 could not yet bring ABI stabilization (so you could ship binaries of libraries to other developers and have them work in future Swift updates). But hey, the upside there is that people that want to ship Swift libraries have to give you source - who doesn't want that!

    • ... my Stevens unix systems programming book (which applies t to OS/X too) from the mid 90s is still mostly relevant today.

      • While C remains backward compatible, C99 and C10 have added quite a lot of stuff to C. But due to Microsoft's refusal to support newer C standards in Visual Studio and the problems that mixing new C with new C++ brings, they aren't in widespread use.

        • While C remains backward compatible, C99 and C10 have added quite a lot of stuff to C. But due to Microsoft's refusal to support newer C standards in Visual Studio and the problems that mixing new C with new C++ brings, they aren't in widespread use.

          It appears to me that the standards committee is actively sabotaging C. The latest standard made some things "optional", which in effect means that a vendor can advertise their C compiler as C10 conformant even though they don't support VLAs (for example).

          I do not understand why the committee would encourage breakages between compilers - a fully conformant C program was (until now) gauranteed to work on all conformant implementations. This is no longer the case.

      • Re:Meanwhile, back in C land... (Score:5, Insightful)

        by west ( 39918 ) on Monday September 19, 2016 @07:19AM (#52916041)

        Well, C was created in 1972, so that did give them some 20+ years before stability...

        • Re: (Score:2)

          by Viol8 ( 599362 )

          Yes, but its not so much the language, more than the core Unix API has remained pretty stable now for going on 30 years.

  • One word: Courage. (Score:5, Funny)

    by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Sunday September 18, 2016 @10:54PM (#52914963) Homepage

    The courage to move on, to do something new that betters all of us.

    The Swift 2.0 language is more than 12 months old. It has its last big innovation about 6 months ago. You know what that was? They deprecated prefix and postfix operations, they made it smaller. It hasn't been touched since then. It's a dinosaur. It's time to move on.

    • I wish I had mod points...
    • The courage to prepare for the right job interview "you're swift 3? sorry we're looking for 2.3 people"

  • Lol (Score:1)

    by Anonymous Coward

    Apple being Apple

  • Fork You Apple! (Score:2, Insightful)

    by williamyf ( 227051 )

    If anyone is anoyed by this "Breaking of source" change, feel free to fork the hell out of the project (is open source after all).

    Me? I do not speak Swift yet, and for the looks of it, will wait until version 8 or so to start learning.

    • Re: (Score:1)

      by Anonymous Coward

      I do not often code, but when I do, I prefer multi-platform languages. It takes courage to use what works, instead of what the cool kid company is pushing with their headphone-less phone.

      • Since Swift is open source, it's already been ported to many platforms. It's on Linux (which Apple officially supported) and Windows and even Android now...

        If you are ignoring Swift because of your irrational hatred of Apple, you are only hurting yourself and your future employability. But I do thank you for making it even easier for me to find work.

        • Re:Then use Swift (Score:4, Interesting)

          by goose-incarnated ( 1145029 ) on Monday September 19, 2016 @03:35AM (#52915557) Journal

          Since Swift is open source, it's already been ported to many platforms. It's on Linux (which Apple officially supported) and Windows and even Android now...

          So is DOSBox. Doesn't mean much. The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

          If you are ignoring Swift because of your irrational hatred of Apple, you are only hurting yourself and your future employability.

          I dunno hey - I soundly ignored iOS, Obj-C and all Apple development and it hasn't done anything to my employability at all. I expect similar by soundly ignoring Swift.

          But I do thank you for making it even easier for me to find work.

          Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible. The amount of non-Apple development work out there dwarfs the Apple-only development work. Hell, the Apple-only work being offered is so tiny I doubt it even makes a margin-of-error difference? Maybe four orders of magnitude difference? Less?

          • The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

            Or, just maybe, everyone else would wait for ABI stability before trying a port?

            You are going to look SO silly when Android adopts Swift (or forks it)...

            Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible

            I can't help but laugh at a curmudgeon who ignores a widely used programming lang

            • The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.

              Or, just maybe, everyone else would wait for ABI stability before trying a port?

              You are going to look SO silly when Android adopts Swift (or forks it)...

              Why would I look silly? I hardly ever develop for Android either

              Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible

              I can't help but laugh at a curmudgeon who ignores a widely used programming language

              Whoa there cowboy - you're getting a little ahead of yourself. Swift is "widely used"? Maybe in mobile development (and even that is probably debatable), but in the Aerospace, Military, Healthcare, Finance, Agriculture, Automotive, Manufacturing, Retail, Mathematic, Web, Modeling, Design, Embedded and Desktop industries/environments the usage is too small to even be accurately counted.

              and operating system describe themselves as "flexible".

              I guess then I'm even MORE flexible than you are, since I have worked with scads of non-Apple systems and platforms also...

              Sure you have. And I'm the King of England (tip: the actual

    • Why ? It will be hugely different from version 9 (or so).

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday September 18, 2016 @11:00PM (#52914991)
    Comment removed based on user account deletion

    • Re: (Score:1)

      by Anonymous Coward

      Meanwhile, us trusting fools who hitched our wagons to Microsoft can still run C# from the .Net 1.x era (circa 2002) in the very latest runtime and not get burned as long as we didn't do something extremely outlandish with it. (Though if you have VB from the pre-.Net era, you're a fucked dinosaur.)

      • Nah, VB6 still runs perfectly on Windows 10 (and will for quite a while) (but I certainly would not recommend starting a new project in VB6)..

    • Yeah, I was wondering when someone would point out that swift is hardly the only language to follow this model...

    • Re:welcome to python (Score:4, Informative)

      by MSG ( 12810 ) on Monday September 19, 2016 @01:45AM (#52915361)

      Python was initially released in January 1994, almost 23 years ago. Since then, some libraries have been deprecated, first producing warnings, and later being removed. That process gave users and developers time to update the code without completely breaking following an upgrade. Backward compatibility was reasonably well maintained until 3.0, which was released in parallel with 2.6. Python 2 is still maintained while developers port code to Python 3.

      That's a big contrast from Swift, which was initially released almost exactly 2 years ago, and made significant backward-incompatible changes without an interim version that retained compatibility. Python's not perfectly backward compatible, but it's a whole lot better than this.

      • Re:welcome to python (Score:5, Insightful)

        by h33t l4x0r ( 4107715 ) on Monday September 19, 2016 @02:04AM (#52915381)

        Python 2 is still maintained while developers port code to Python 3.

        That's one way to put it. Another way to put it would be:

        Python 2 is still maintained because developers aren't porting their code to Python 3.

        It's 9 years later, at some point Python is going to have to give up on Python 3 and move on to a Python 4 that is backwards compatible with Python 2.

        • Re: (Score:3, Informative)

          by Anonymous Coward

          Python 2 is still maintained because the installed base of useful Python 2 code is extremely big. People are porting to 3, but it takes time.

          And the actual changes are much smaller in Python 3, here the new Swift is completely changing a lot of APIs without notice nor deprecated phase.

        • Python 2 is still maintained because developers aren't porting their code to Python 3.

          It's 9 years later, at some point Python is going to have to give up on Python 3 and move on to a Python 4 that is backwards compatible with Python 2.

          It's been quite some time since I've seen a python package that doesn't work with Python 3. What packages do you use that aren't Python 3 compatible, at least through six or some layer?

          At this point, any libraries that haven't been updated for 9 years to handle Python 3 are likely dead projects and you should consider migrating to newer packages with appropriate bugfix and security updates, rather than delaying Python 3. Python 3 is stable and great. It's handling of strings and binary data is much more con

          • Don't hold your breath waiting for distros to move to Python 3. Linux depends on too many Python 2 scripts for it to happen in my lifetime.

        • Re: (Score:1)

          by MSG ( 12810 )

          > Python 2 is still maintained because developers aren't porting their code to Python 3.

          That's not really what I see. At Python meetups and conferences, the Python developers I meet are near unanimous in their praise for Python 3. On my workstation, there are more packages that depend on python3 than on python. Porting is clearly happening.

      • Re: (Score:2)

        by west ( 39918 )

        To me this makes it crystal clear that *now* is the only time to make significant changes lest you suffer Python's fate of essentially forking the user base.

        Making breaking changes over 22 years is a disaster. Making them over 2-3 is survivable.

      • Re: (Score:1)

        by Etcetera ( 14711 )

        Python was initially released in January 1994, almost 23 years ago. Since then, some libraries have been deprecated, first producing warnings, and later being removed. That process gave users and developers time to update the code without completely breaking following an upgrade. Backward compatibility was reasonably well maintained until 3.0, which was released in parallel with 2.6. Python 2 is still maintained while developers port code to Python 3.

        That's a big contrast from Swift, which was initially released almost exactly 2 years ago, and made significant backward-incompatible changes without an interim version that retained compatibility. Python's not perfectly backward compatible, but it's a whole lot better than this.

        You sound like a Fedora admin.

    • Re: (Score:2)

      by ssam ( 2723487 )
      If you wrote a python program any time in the past 15 (maybe longer) years that worked in the current version of the time, it will still work in a supported version today. Though you might get some deprecation warnings, and you should probably start thinking about migrating to 3.x.
  • The only breaking change worth having in a released language is a compilation error if a space character is surrounded by white space characters. The space character exists in writing to break up words (ie, a series of non-white space characters), and the same should be true for programming. I'd be so happy if that were made a compiler breaking change in all of the major languages. I'd push so hard to upgrade to the latest version for all of them.

    • Re: (Score:2)

      by dgatwood ( 11270 )

      So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

      • So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

        I think they're saying they want spaced indentation to be illegal, and force you to use tabs. Not sure why that would help anything.

        • I think they're saying they want spaced indentation to be illegal, and force you to use tabs. Not sure why that would help anything.

          When moving around lines in a file, or moving them in and out of some scope, I find that it's less annoying when dealing with tabs than compared to a file with spaces. It's easier to get the indentation correct in those cases.

      • So... what you're saying is that you want a language where indentation is illegal? Sort of the anti-Python?

        No, I want the character whose soul purpose is indentation, to be used for indentation (ie tabs); and the character which exists for separating non-whitespace characters to not be used for indentation (ie spaces).

  • Now Apple gets to join in on the fun of deliberately breaking things, especially non-blessed ports.

  • Comment removed based on user account deletion

  • "Move fast and break things,"

    It's such a bad saying that even Facebook has discarded it.

    • Re: (Score:2)

      by Etcetera ( 14711 )

      "Move fast and break things,"

      It's such a bad saying that even Facebook has discarded it.

      Everyone does, as they grow up.

  • Now it won't ever be implemented. Shoot we would still be having an IE 6 internet too if it were not for MS forcing corps to stop using it. People hate change and it is impossible unless you kill the original but good luck as Swift is open source

  • This thread is full of anti-Apple haters (Score:4, Informative)

    by Anonymous Coward on Monday September 19, 2016 @06:43AM (#52915945)

    Everybody whining here clearly hasn't written any Swift code and is only interested in bashing Apple. Maybe you should be asking what actual people using Swift think of this.

    Well, I'll tell you as one.

    - The Swift syntax changes are annoying to spend time on, but minor.
    - Apple's migration tool is helpful and makes fixing go fast.
    - It was no surprise or secret that the syntax was going to change. They said all this upfront and we all knew this was coming.
    - Swift on Linux and other platforms only started working less than a year ago. There is not as much code to transition.

  • And Thus the Reason for Swift 2.3 (Score:5, Informative)

    by rsmith-mac ( 639075 ) on Monday September 19, 2016 @08:17AM (#52916225)

    What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts. Besides the newer version 3, Apple is also continuing to develop/support Swift 2.x. The already-released Swift 2.3 [swift.org] is Swift 3's counterpart for developers who would like to stick with Swift 2.x code.

    Swift 2.3 is a minor update from Swift 2.2.1. The primary difference between Swift 2.2.1 and Swift 2.3 is that it is intended to be paired with Apple's macOS 10.12, iOS 10, watchOS 3, and tvOS 10 SDKs. It also updates the underlying LLVM and Clang versions to match with those in the Swift 3 compiler.

    I don't imagine Apple will support Swift 2.x forever. But for the time being, Swift 3 is only as source-breaking as you want it to be. Developers who need Swift 2 compatibility can roll on with 2.3.

    • Re:And Thus the Reason for Swift 2.3 (Score:4, Funny)

      by OzPeter ( 195038 ) on Monday September 19, 2016 @08:44AM (#52916359)

      What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts.

      Stop confounding us with facts! I was halfway through sharpening my pitchfork when I saw your comment and now I'll also have to cancel that Amazon order for my torch oil.

    • Swift 3 is as compatibility-breaking as people made it out to be. But hey, you can choose to stick with Swift 2.3 if you want to suffer even more compatibility breakage when Swift 4 comes along.

      Apple apologists should just admit that Apple can't decide how to design either a library or a language.

    • At some point, Apple will not allow apps using Swift 2.3 into the App Store. I don't think this split will exist for very long. Apple has the advantage of controlling both sides of the ecosystem.

  • timberland pas cher [wpredsfsd.com] it's ok to wipe it with wet rag. But when it comes to imitated furs such as the black upper of air Jordan, you should pay attention to the dampness of rag. Otherwise it will get worse. But this method can not be employed into shoes with cloth upper such as Nike air Garnett III. Since such uppers find no ways to clean. Then, it would be better to unfasten the ties and wash it, which will make your cleaned shoes more attractive. Last but not the least; you should wear your shoes under natu

  • I've always seen Swift as a way of keeping application model logic off of competing mobile platforms/languages, specifically C++ (which Apple supports extremely well on iOS BTW). I view it as the new PowerBuilder --- remember those "LEARN POWERBUILDER OR LOSE YOUR JOB" ads?

    How much money did Corporate America p*ss away on PowerBuilder? ... but I digress ...

    The company open sourced Swift once it was clear Windows Phone was dead, but now that the app market is in decline, they need to squelch the experiments

  • A non-programming friend downloaded Swift Playgrounds app on his iPad to learn Swift programming. Not sure why it introduced him to nested functions right off the bat. Anyway, he's frustrated because his code doesn't work and he wants someone else — probably me — to figure out why. I told him if he wanted to be a real programmer he needed to debug his own code before asking someone for help.

  • For anyone that is writing Swift 3 modules (that other people will use in their projects):

    You may be interested in this template and recipe that explains how exactly to set up your project and Xcode settings properly.

    It is at: https://github.com/fulldecent/... [github.com] /selfpromo

    Hopefully Swift 4 and other updates will not require every developer to redo everything each time.

  • Very easy transition (Score:3)

    by cerberusss ( 660701 ) on Tuesday September 20, 2016 @02:16AM (#52922121) Journal

    I'm working on a small mixed Objective-C/Swift project. The API was provided, and is in Objective-C so no changes there. The UI code (i.e. all view controllers) are all in Swift, and consist of about ~30 classes. Moving from Swift 2.3 to 3 was quite easy with the migration tool, and took me about two hours.

Slashdot Top Deals

Never test for an error condition you don't know how to handle. -- Steinbach

Close