Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Cellphones IOS Open Source Programming Software Apple

Apple's Swift 4.0 Includes A Compatibility Mode For 'The Majority' Of Swift 3.x Code (infoworld.com) 122

Posted by EditorDavid from the throwing-exceptions dept.
An anonymous reader quotes InfoWorld: Swift 4.0 is now available. It's a major upgrade to Apple's Swift, the three-year old successor to the Objective-C language used for MacOS and iOS application development. The Swift 4 upgrade enhances the Swift Package Manager and provides new compatibility modes for developers. Apple said Swift 4 also makes Swift more stable and improves its standard library. Swift 4 is largely source-compatible with Swift 3 and ships as part of Apple's Xcode 9 IDE...

Swift 4's new compatibility modes could save you from having to modify code to be able to use the new version of the compiler. Two modes are supported, including the Swift 3.2 mode, which accepts most source files built with Swift 3.x compilers, and the Swift 4.0 mode, which includes Swift 4 and API changes. Apple said that some source migration will be needed for many projects, but the number of source changes are "quite modest" compared to many previous major changes between Swift releases.
Apple calls Swift 4.0 "a major language release" that also includes new language changes and updates that came through the Swift Evolution process.
This discussion has been archived. No new comments can be posted.

Apple's Swift 4.0 Includes A Compatibility Mode For 'The Majority' Of Swift 3.x Code More

Apple's Swift 4.0 Includes A Compatibility Mode For 'The Majority' Of Swift 3.x Code

Comments Filter:

  • The *majority* of code (Score:3, Funny)

    by Hognoxious ( 631665 ) on Saturday September 23, 2017 @01:41PM (#55250879) Homepage Journal

    Don't you just love things that nearly always work?

    • Re:The *majority* of code (Score:5, Insightful)

      by Dutch Gun ( 899105 ) on Saturday September 23, 2017 @02:23PM (#55250999)

      I used to be somewhat critical of the compatibility-breaking change of Swift, but I'm wondering if this isn't a decent approach for the long-term benefit of the language. It certainly seems to be better to make incompatible changes early in the language's adoption life cycle than to wait too long, then break things, which causes a lot of problem when there's a huge existing body of source code. Moreover, everyone was warned well in advance that Swift would be making changes up to at least version 3 (and apparently, slightly beyond), so it's not like this should catch developers off guard.

      I'd imagine the benefit of making changes post-release is that you can account for real-world feedback based on actual experience with the language, rather than purely theoretical designs. I'd have to think this makes for a better language in the long run.

      The big caveat here is whether the Swift developers stop tinkering with the core language and allow it to stabilize for the long term, at least in terms of backwards compatibility.

      • Re: (Score:1)

        by Anonymous Coward
        As a developer, I much prefer compatibility breaking improvements than maintaining compatibility and never making it around to improvements. If developers were better at collaboration and managing chaos (maybe if we were psychic and never changed jobs hah), I think breaking compatibility would be the more popular choice.

      • I almost put "nearly" in italics. Probably should have done.

        Incompatibility per se[1] isn't the issue. It's this #smegma or whatever it is that doesn't work for the *minority* of code. In what way does it not work? Compiler warning[1]? Compiler error? Just do random shit?

        [1] Who takes notice of those?

        • My response was slightly tangential to your point, I suppose. Yeah, I agree an issue is definitely the behavior of that "nearly." If it simply flags an error, no problem - you correct it manually and move on. If it's more ambiguous, then that could be a problem. I looked at the linked article, and didn't see an immediate answer to this. Not that affects me in any way, of course, as I'm not using Swift. Objective-C is far better at interop between my C++ code and the Cocoa APIs, so that's what I'll con

          • Is this sort of like the whole community of Delphi Pascal users who have cut themselves of from whatever Embarcadero is selling and are still using Delphi 7?

        • Compiler errors, dude. Lots and lots of compiler errors.

        • Every new version of Swift shifts some things around slightly, mostly those changes result in error messages - usually clear enough the fix is obvious right away.

          Also though, with each new release of Swift they add new compiler warnings, so usually you end up with a number of new warnings across your codebase. However these have generally been really helpful warnings, that were pointing out potential problems and really did require a fix. That has been a very useful component of each new version of Swift.

  • Why Swift over Modern C++? (Score:1)

    by Anonymous Coward

    What benefit does Swift have over Modern C++ (C++14 & C++17)? Why should I choose Swift instead of Modern C++?

    • Re:Why Swift over Modern C++? (Score:5, Informative)

      by dottrap ( 1897528 ) on Saturday September 23, 2017 @02:37PM (#55251045)

      - Emphasizes compile time & native code much like C++
      - More powerful type system
      - Safer language by design
      - Native string type built into the language that is Unicode compliant (not a library like C++)
      - No header files
      - Large standard library (Foundation) being made cross-platform with built-in things like networking, date handling, file system abstractions, regex
      - Features to replace the runtime things that GUI programmers found useful in Obj-C/Cocoa, but doing them at compile time and with stronger type safety
      - Syntax is not constrained by C legacy compatibility
      - Will eventually have stable ABI so you can share binary libraries

      • "Eventually" will have a stable ABI. In the mean time, they still break the whole language about as often as C++ releases a new revision.

        Now I feel about about already having used the Apple "courage" joke today.

        • Re: (Score:1)

          by Anonymous Coward

          It's a new language, you don't have to use it yet. This drastic breaking is to make it a better language in the long run. Even though C++ is certainly the more practical language at the moment, you have to admit it carries some terrible historical decisions along with it.

          Assuming Swift stabilises down in a few years, maybe consider it then.

      • Re: (Score:2)

        by shmlco ( 594907 )

        Ummm... you forgot optionals and closures being first-class citizens.

        As to the OP, if you want to write software for OS X / iOS / Apple TV / Apple Watch, you can't do so in C++.

        • I didn't forget. I just didn't think it would be interesting to the OP.

          - I didn't think optionals would be a familiar concept to a C++ programmer. They are also integrated with the type system and I already listed the type system.

          - C++ has lambda functions now. Swift has simpler syntax, but I already listed syntax.

          I am curious if you say C++ lambdas are not first-class citizens. What are examples of its limitations?

          • Re:Why Swift over Modern C++? (Score:4, Insightful)

            by _merlin ( 160982 ) on Saturday September 23, 2017 @10:14PM (#55252681) Homepage Journal

            C++ lambdas don't automatically extend scope of capture expressions, so you need to know what you're doing when you use them. If the lambda is going to outlive its containing invocation scope, you need to capture by copy or move. C++ gives you more low-level control over how the lambdas behave.

            C++17 adds optionals, variants and any type to the standard library. They're inspired by the corresponding types in Boost, but with a lot of the rough edges cleaned up. There's some argument to be had over language vs library, but the C++ way has always been to prefer library.

            Claiming that you can't write OSX apps in C++ is just silly - I do it all the time.

        • Re: (Score:3)

          by jeremyp ( 130771 )

          You can write software for Apple OS's in C++. You do need a layer of Objective-C++ for the Cocoa interface though.

      • Re: (Score:2)

        by Megol ( 3135005 )

        I think a potential for a future stable ABI isn't worth much when they can't even release an update of the main language that is compatible with existing code.

  • You know, ReactOS runs the majority of the Win32 programs. So, who's ditching Win10 and heading to ReactOS?! ;)

  • This is why I jumped off the Apple treadmill (Score:3, Interesting)

    by phantomfive ( 622387 ) on Saturday September 23, 2017 @02:08PM (#55250969) Journal
    This is why I jumped off the Apple treadmill and stopped using their proprietary languages (yeah, I know the languages are technically open, but for practical purposes the languages change at their whim). When I need to write for iPhone, the meat of the code gets written in C or C++, which is stable (and has the added benefit of being portable to Android or anywhere else).

    For the code which I write in Apple's languages, I use a simple subset of the language, trying to avoid features that are likely to be changed in the future. It makes me sad because there are some nice features, but I don't want to use them because the pain of rewriting code (for no reason) is worse than the benefit I get from those features.

    • Ah, come on phantomfive!
      You are smarter than that.
      Just because Swift 4 is out, it makes Swift 3 not dead. And as both compile down to ordinary *.o/*.lib/*.so files, they can interlink each other.
      No need to rewrite Swift 3 code to Swift 4 ... just transform old code into libs and use the new Swift for new projects.
      If the old code can't be a lib, just keep it as Swift 3 and use the old compilers for it, problem solved.

      • Ah, come on phantomfive! You are smarter than that.

        Thanks :)

        Just because Swift 4 is out, it makes Swift 3 not dead. And as both compile down to ordinary *.o/*.lib/*.so files, they can interlink each other.

        How long do you think Swift 3 will be maintained?

        • Does not really matter how long it will be maintained, as long as you keep the tool suit around.
          As it is open source, and there are already alternative compilers, I would assume you have a decade or more.

          Actually I would like to do some work with Swift, too. But I have no idea about a program I could write. Except my idea of a kind of HyperCard clone :D but I guess I make that for Android first, and not iOS.

          • You could write a decent frontend for the Stockfish chess engine. There's one available for OSX, but it isn't very good (it would be nice if it let you investigate variations without resetting the board, for example).

      • Re: (Score:2)

        by jeremyp ( 130771 )

        You can't link Swift 3 to Swift 4. They haven't nailed down the ABI yet.

    • That's exactly what I felt when I was doing iOS development. All my code was littered with yellow "depreciated" warnings. Trying to keep stuff "current" was an exercise in futility, because they would just depreciate a load of other stuff with the next iOS release.

      • The word is deprecated, not depreciated.

        And you've got to fix those warnings, no matter who caused them. Leaving them hanging around is a recipe for things getting worse and worse, no matter what language or platform.

        • No they're not, but I take it you've never developed for iOS

          • No what aren't?

            Yes, I'm an iOS developer. Have been since 2008, and a developer in general since the 1980s. Seriously, always fix your errors then your warnings before you do anything else. Anything else will bite you in the arse.

    • Claiming backwards compatibility is easy when your reference point was standardized 15 years after the creation of the language.

      (Note: this metric still leaves Python3 as fair game.)

      • By the time your language is released as the premier language for your platform (which Swift is) you better be sure that you got it mostly right.

    • It makes no sense to to keep a new language tied to features introduced at start, because you find slightly better ways or syntax to do what you were trying to do before - especially when you heavily factor in community feedback, as Swift does far better than almost any language I have seen (Java actually did a decent job of this earlier).

      In practice Swift has been great to use - you have a large timeframe to migrate code to newer versions (hence the backwards compatibility mode), and so far even on very la

      • Swift is the first language I've seen that I think has a real shot at displacing C/C++,

        Shake your head and wake up man, you're in the Apple bubble. Swift will never be used much on non-Apple platforms, just like Objective-C before it (which frankly, is also a much nicer language than C or C++).

        • Shake your head and wake up man, you're in the Apple bubble. Swift will never be used much on non-Apple platforms

          I'm afraid it is you who seem to be very much asleep [ibm.com].

          just like Objective-C before it

          That is why I know I'm right on this, because I fully agree with you about ObjC - I could tell that was not going to be of use outside of Apple's platforms (though I liked working in it anyway).

          But having done a wide range of programming in the past, from Java to C and C++ and Javascript and Lisp and various flavo

          • IBM cloud is your example? Really?

            • It's a completely non-Apple platform; in general Swift server side development has been advancing fairly well and is not just tied to IBM.

              You truly cannot see the value of using Swift server-side, as well as on the client?

              I wonder if you even knew that Swift has been running on Linux for quite some time now...

              • Uh, these aren't even arguments. Objective-C has been running on Linux since the 90s. Still hasn't taken off.

                • Uh, these aren't even arguments.

                  They are, I'm sorry you cannot see them, but to paraphrase an old saying, you can't lead a horse to think...

                  Plainly you are being obtuse, and cannot see the larger picture here. I'll let you have the last response so you can firmly cement your position in history for me to look back on and laugh ten years hence.

                  • So do you have any actual reason to think that C++ will be overtaken by Swift, or is that just your hope?

          • Shake your head and wake up man, you're in the Apple bubble. Swift will never be used much on non-Apple platforms

            I'm afraid it is you who seem to be very much asleep [ibm.com].

            Wellll.... I very much enjoy my hacking in Swift. But I don't give it a big chance of taking off among the open source crowd. Yeah it runs on Linux, and I love it for that. But I think we'll see adoption like Mono: used here and there, but not in any major way.

            That said, Swift strikes a number of very nice balances in my opinion. I really like the expressiveness of the language, especially how easy it is to throw in some .filter {} , .map {}, and what have you.

        • ..just like Objective-C before it (which frankly, is also a much nicer language than ... C++).

          Objective-C has one or two nice syntactic tricks, but it's a very weak language compared to C++. About the only thing that it had going for it was that Apple provides a decent set of libraries- not like that isn't also available for C++, but at least Objective C had "one true standard" for such things.

          • Objective-C has one or two nice syntactic tricks, but it's a very weak language compared to C++.

            Except for anything "Smalltalky" that Objective-C can do but C++ can't? I mean, I agree that Objective-C has quite a few problems, but C++ turned out to be a clusterfuck with no clear direction.

          • Objective-C has runtime type binding and introspection.
            C++ has operator overloading.

    • When I need to write for iPhone, the meat of the code gets written in C or C++

      Then I wonder what you write, because the meat for most apps basically is the interface. For which Apple gives you a nice framework, UIKit. Are you saying that you avoid UIKit? Not trying to be sarcastic or anything, just genuinly curious what kind of apps you build.

  • Meh. NBD (Score:5, Interesting)

    by Anonymous Coward on Saturday September 23, 2017 @03:39PM (#55251231)

    I have a whole bunch of apps, going back years (ObjC). I have also been programming Swift since announcements.

    I don't need no steenkin' compatibility modes; mostly because I tend to keep in my lane, and don't use too may shiny "tricks."

    It took about five minutes apiece for me to fully (and buglessly) convert all my apps. More than 40,000 lines of Swift.

    Several of the apps have already passed App Review, and are in the wild.

    However, all you Apple haters can have all the fun you want, slagging Apple. I've been hearing the same lame shit since the mid-'80s. You ain't exactly blazing a new trail, here.

  • This doesn't exactly sound like a stable platform to develop on if they can't even manage full backwards compatibility at compile time, never mind run time. Unix C programs I wrote back in the 90s I can still compile today on modern compilers - Swift will probably just be another language footnote in 20 years time but even if it isn't, I suspect the chances of being able to compile a program written in Swift 4.0 unchanged in 2037 I suspect will be near zero.

    Seems like Apple is following MS in the rush to ma

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close