Slashdot Mirror
Apple Releases First Preview of Swift 3.0 (macrumors.com)
DaGoatSpanka quotes a report from MacRumors: Apple yesterday released the first preview build of Swift 3.0, a major update to Apple's open source Swift programming language. Swift 3.0's official release is expected to come in late 2016 after proposed changes are finalized. The Swift 3.0 preview can be downloaded from the official Swift website. There are versions of Swift 3.0 available for Xcode 7.2, Ubuntu 14.04, and Ubuntu 15.10. [Swift 3.0 is not source compatible with Swift 2.2 as it introduces source-breaking changes, but going forward, the goal is to make Swift 3.0 source compatible with future Swift language updates.] Swift 3.0 will likely be shown at Apple's upcoming Worldwide Developers Conference (WWDC).
Last release broke for loops, what was broken now? If statements??
Really? So you are saying my PDP11 ML knowledge isn't obsolete? Thanks for the tip. It isn't trolling: it is a warning to avoid languages controlled by a single corporate entity. They can pull things from under you at their whim. Also, what a laugh: Swift 2.2 was released on MARCH 16, 2016!
C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today. Swift 2.2 was released in MARCH 16, 2016, and is already obsolete. Ridiculous.
C++ advances and still maintains backward compatibility. It does matter. If you learned C++ 10 years ago, that knowledge still applies today.
There have been breaking changes in C++ in the past.
Swift 2.2 was released in MARCH 16, 2016, and is already obsolete. Ridiculous.
Hardly obsolete. No-one is saying you now can't still write Swift in 2.2 or even 1. Swift is not included in iOS and is instead bundled with the App that uses it. You just need to use the tooling version that supports your desired Swift version.
I am Slashdot. Are you Slashdot as well?
Apple stated when Swift 1.0 was released that it was a work in progress and that there would be a flurry of updates coming and that, while they would maintain binary compatibility, they would not be able to maintain source compatibility as they changed and streamlined the language. Anyone using swift is well aware of this.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Like C? Even C has broken backwards compatibility at times. C started out in the 70's, yet we still have C99. Oh wait, that didn't work, we have C11. 40 years later we're still changing it.
C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers.
Java has methods that are deprecated.
Swift is a pretty new language. It's also a bit of a new paradigm. You start with an idea of what you want in the language, most works, some doesn't, you try again. Some of this breaks backwards compatibility. Better to do this now, then 40 years later.
Not everyone is a lazy shit. It takes about 5 minutes to update a moderately-sized code base from 2.2 to 3.0 syntax. Xcode provides a built-in tool to do it for you, and you just have to fix up the few cases it doesn't find on its own. It's really trivial for anyone who isn't a spoon-fed piece of dirt.
I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98. :) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.
Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.
Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.
Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.
Which, again, you can do, absolutely -- but you don't have to.
Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."
I've fallen off your lawn, and I can't get up.
And Qt5 breaks code written for Qt4 which, in turn, breaks code written for Qt3. And Windows 10 breaks drivers written for Windows 8. And Linux 2.6 broke code written for Linux 2.4 which broke code written for Linux 2.2. And I'm pretty sure modern C broke code written for ye olde C.
That's what major version numbers are for: to announce Major Breakage (or possibly even General Breakage) and his mighty army of doom.
"Everybody's naked underneath" -- The Doctor