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

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.

Comments

The *majority* of code

[Hognoxious]

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

Re:The *majority* of code

[Dutch Gun]

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:The *majority* of code

[Hentes]

At least Python only breaks compatibility every 10 years or so, not on an annual basis. And the transition from 2 to 3 was handled pretty well, with __future__ allowing devs to write forwards compatible code before the switch, a 2to3 converter that mostly automated the migration itself, and continued development of the 2 branch afterwards. As for people arguing about changes that's true for every feature in every language and has little to do with compatibility.

Re:The *majority* of code

[Dutch Gun]

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 continue to use.

Re:The *majority* of code

[dottrap]

This doesn't break shipped apps. Any app using Swift right now deliberately has everything compiled and bundled to be self-contained. Changes to Swift have no impact on shipped binaries.

This is why I jumped off the Apple treadmill

[phantomfive]

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.

Re:This is why I jumped off the Apple treadmill

[phantomfive]

That's a reasonable risk/reward position. It's good that the state of the art moves forward, and it's also good that stable not-moving options exist too.

In general the problem is that these languages aren't moving forward. They are just churning. In some cases, the only difference is the order of parameters in a method.

Re:This is why I jumped off the Apple treadmill

[phantomfive]

How much say did you have over the directions that C and C++ have taken lately? None.

It's the nature of the changes. C++ and C both have heavy commitment to backwards compatibility (your stupid examples to the contrary notwithstanding). Apple has a 3 year commitment to backwards compatibility. They change things for cosmetic reasons.

C++11 altered the "export" keyword's behavior. C++17 removes support for trigraphs.

ok, you convinced me. I'll use C for better compatibility.

Re:This is why I jumped off the Apple treadmill

[edxwelch]

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.

Re:This is why I jumped off the Apple treadmill

[shmlco]

Actually there's a swift-evolution project where quite a few people (including non-Apple employees) are involved with Swift language design, proposals, and evolution.

https://github.com/apple/swift...

And as there's a Swift roadmap out there, I don't think the whole "on a whim" thing has merit either.

Re:This is why I jumped off the Apple treadmill

[BasilBrush]

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.

Re:Why Swift over Modern C++?

[dottrap]

- 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

Re: Why Swift over Modern C++?

[Entrope]

"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.

Meh. NBD

[Anonymous Coward]

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.

Re:Why Swift over Modern C++?

[jeremyp]

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

Re:Why Swift over Modern C++?

[_merlin]

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.

You need to look outside your own bubble

[SuperKendall]

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.

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 flavors of assembly, sometimes all server, sometimes all client, sometimes dedicated hardware... because of the broad range of past experience I have the ability to tell now when a language will be a good fit for a project. And Swift is a VERY good fit for both client and server work, and after some time, even low level work.

Swift is not just controlled by Apple, at all - it has a thriving community driving development, and not just from Apple devs at all. It's just a really good mix of ides from many different modern languages, with a very well thought out syntax and pragmatic approach to development.

But it's way more than that, it's one of the few languages (maybe the only one?) that really embraces what LLVM can do and takes full advantage of it...