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.
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.
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.
Irony: Agile development has too much intertia to be abandoned now.
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.