Swift 5.0 release process
swift.org
swift.org
Compare this to Go (no major revisions after 6 years, probably a backwards-compatible major revision in 2-3 years) and Rust (no major revisions after 3 years, but with a mechanism called "editions"). To say nothing about Java or C#.
Is this really true? Looking through 4.0 release notes I see some incompatible changes like:
SE-0164 Remove final support in protocol extensions
SE-0160 Limiting @objc inference
> When the Swift 4.2 compiler is working with Swift 3 code, it identifies its language version as 3.4. As a result, you can use conditional compilation blocks like #if swift(>=3.4) to write code that’s compatible with multiple versions of the Swift compiler.
Yes, you can continue compiling v3 code with a v4 compiler with a flag, but if you compile your v3 code without a flag, your code may fail to compile. So while there may not be a compiler breakage, there is a language breakage between v3 and v4, and apparently there will be another one between v4 and v5.
It's not the Great Renaming, and it might not be fair to the Swift project itself, but unless I can compile a project using the 10.13 and 10.14 SDKs without source changes (which you can in Objective-C), the impression is that Swift doesn't have source compatibility.
Swift 5 represents a stable ABI. That means from this point forward all binaries built with Swift 5 or later will run against a newer Swift stdlib.
The ABI is entirely separate from source compatibility. Swift is already source compatible and the bar for a source-breaking change is extremely high.
The number 5 _also_ implies significant breaking changes. Otherwise, why wouldn't it be Swift 4.3?
Removing Swift 3 compatibility mode (which was part of Swift 4) is itself a major source-compatibility breaking change, even if nothing else.
But that's an unfair comparison since its "binary" format is non-native.
I'm pretty sure C++ doesn't prescribe any particular ABI for implementations to adhere to. There was even a paper in 2014 about defining a portable ABI, and I don't believe it was adopted [0].
In particular, MSVC uses a different ABI than the *nixes, and MSVC's ABI isn't guaranteed to be stable across major compiler releases. In addition, libstdc++ 5.1 had a significant break for C++11 std::string and std::list [1].
[0]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf
[1]: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.htmlC++ implementations generally use a calling convention that is stable ABI on each platform, but different platforms may have a different ABI. In the past the MSVC ABI was different from most posix platforms, I’m not sure if that carries through to win64.
The easiest way to explain why C++ the language doesn’t prescribe the calling convention ABI is that you may want to compile code on different cpu architectures. There’s no way you could (sensibly) have the same calling convention :)
Huge pain for closed-source libraries.
ABI stability at a language level is for code (replace syntax with your language of choice):
class Foo { virtual void bar();
int _i;
float _f;
bool b;
int bitfield : 5;Should be stable across multiple compilers and versions. This is what swift currently does not have.
This is vs. source defined ABI, e.g.
class Foo { virtual void bar(); virtual void wibble(); int i; float f; }
vs.
class Foo { virtual void wibble(); virtual void bar(); float f; int i; }
In this example Foo is API stable, and the language ABI means either definition is ABI stable, but as a publicly exposed API it is not ABI stable. C++ defines vtable layout in terms of order of definition (so changing the order of virtual methods is not stable). And you have the source compatible reordering of i and f, which is just as ABI breaking in C++ as it is in a C struct.
This is all about ABI - can binaries compiled with one version of the compiler interoperate with binaries compiled with a different version.
API stability is easy - C++ has an extremely stable API. Swift is pretty stable apparently.
SomeLibrary.h:
class Foo {
virtual void bar();
virtual ~Foo();
The library is compiled into SomeLibrary.dll,dylib,so or what have you.
Your program uses this:
void my_cool_function(Foo* foo) {
foo->bar();
Later on the library makes a change, and adds a new virtual method wibble(). The API is stable -- they haven't removed Foo::bar, and they haven't changed its parameters or return type. But this API change can break the library ABI if it declared the new virtual method in the wrong part of the class, because vtable ordering is defined as being order of declaration.
So there are two aspects of ABI compatibility. First, does a given API result in the same ABI irrespective of what compiler version it uses. The second is, given that your language is ABI stable, are your changes to the API also ABI stable. C++ is notoriously bad at this, because of foot guns like vtable ordering, changes to binary layout of superclasses, etc.
Swift is at least in existing versions even less stable, where you're not necessarily guaranteed that a single API will get the same ABI depending on what things it is compiled with, and certainly not through even minor compiler version changes - let alone actual language version changes.
Swift 2 to 3 was a little bit of work but the new succinct syntax was worth it.
It doesn’t sound like there will be many breaking changes in 5.0:
“As with Swift 4.2, the vast majority of sources that built with the Swift 4.2 compiler should compile with the Swift 5.0 compiler”
It wasn't even major. I updated several projects from Swift 3 to 4 without issue. The largest project was close to 200k loc and it only took me 20 minutes to get everything up to date.
Just make sure your dependencies aren't in Swift because then you're relying on 3rd parties to update their code. I'll be avoiding all Swift libraries except for PromiseKit (it's so nice!).
I consider it weird that the "where" keyword can't be applied in more places, only in case and for ... in I believe it works. Seems like some weird remnant of "what cool feature of C# could we borrow?" that never really got a full rollout.
Also I would like to have a "not" keyword instead of using the easily overlooked !. Such a nice feature of F# (and Visual Basic?).
Good to see count(where:) coming to the language, I often missed it. And probably is faster than filter since it doesn't create an array of results first.
Apart from that Swift 5 doesn't seem to be super different from 4. But that's what I expected already.
The `where` keyword is also used when defining generic functions/types. As the expression level, it used to be used in `if` too, but that syntax was changed such that it no longer uses `where` (but still retains the same power). Where else were you expecting it to be used?
You can do a non-allocating `count(where:)` today with `lazy.filter(where: …).count`.
It was an absolute nightmare to get a project updated then spend hours and hours fixing stupid issues with dependencies.
Every year since the first has been quick and easy.
https://gist.github.com/lattner/429b9070918248274f25b714dcfc...
EDIT: well, the link does address this concern, so i suppose everything should be fine..
Let's say you have an iOS application written in Swift 5 and you are using AlamoFire. The original promise of an ABI (like the C ABI, the ObjC ABI, COM, JVM, etc) is that AlamoFire could choose to switch to Swift 6 because of the great new async/await features, and you could still use that binary in your Swift 5 application. Because, you know, there is a stable ABI ;-) If you enhance the ABI, that won't be usually possible. E.g. the Swift 5 program won't understand the "new mangling and calling convention" mentioned in the link. Presumably it could be bridged somehow, or maybe not in a useful way ...
Not really. You can add new concepts to an ABI without breaking existing code.
Suppose version N+1 of some compiler adds a new language feature, like async/await or whatever. It might involve a new calling convention and symbol mangling for async functions. However non-async functions would not be affected.
Of course if the library author removes old entry points they will break old client apps, but that's not a property of the compiler.
"Apple’s Chris Lattner, original creator of the Swift language, has recently announced on the Swift Evolution mailing list that ABI stability, one of the goals originally planned for Swift 3, will be postponed."
2. "Newbie hackers" can and have mastered Swift and similarly complex languages.
3. Apple would not be interested in developing a language to "run on servers instead of iOS."
4. Get a life troll.
Why not use Flutter? Even React Native is cross platform. Why are we still using a programming language for a phone app that means we have to write the darn thing twice? Even a RN webview pointing at an IP with code written in whatever-lang is seemingly a better choice.
So, maybe you're just talking about desktop macOS in addition to phone apps?
Source for that claim?
Vapor has some pretty great benchmarks. https://medium.com/@codevapor/vapor-3-0-0-released-8356fa619...
So, when you cherry pick benchmarks, it can _look_ kind of fast... but then the unbiased TechEmpower benchmarks show Vapor operating at 20% of the speed of Gin. Which is 2% of the speed of the fastest Go or Rust web framework.
"50x faster to pick a different language" != "even remotely great performance."
(I have no personal interest in Swift on the server, I use Go/echo)
I did not look if other benchmarks were released but this is probably not the best representative.
I guess the key selling point is, well, being able to use Swift on the server (some people do like the language). It is pretty useful for sure. Certainly not the only choice.
That Swift is compatible with almost nothing on Linux sounds strange, not sure what you mean by that. E.g. I find it particularly nice for writing Apache modules (the Swift C integration is really neat).
P.S.: While Apple puts minimal effort in anything but macOS and iOS, others put significant effort into Swift on Linux. Like IBM.
Note that i'm talking about the language here. The libs are of various quality. But powerful enums & switch + null safety + generics while retaining the ability to be learned easily by any "regular" developer makes it a category of its own.
My secret hope is that someone somewhere is working on a flutter equivalent coded in swift.
And, it still has java underneath, which means everytime you're using a java lib, you have absolutely no idea what the null safety is going to be underneath (which is also the case with swift and objc libs, but which diminishes the attractivness of using the java libs ecosystem)
EDIT: also, value-based programming is highly encouraged by the full support for structs, either mutable or immutable. That's also a huge plus for safety against race conditions.
F#, Ocaml and Haskell come to mind.
Or are there any other reason, more technical ?
Microsoft always positioned it as "use F# for the hard stuff and C# for the rest." The trouble is that C# isn't that bad for the hard stuff, and if you're spending most of your time with C#, then for you it's probably better than F#.
When they made it officially part of .NET, it was the black swan of .NET languages with tooling only for libraries and command line applications.
Afterwards they attempted to position it as a language for ASP.NET MVC applications.
Then they largely left it for the community as F# was one of their very first FOSS projects.
Meanwhile the new MDIL compiler came out for Windows 8.x, followed by .NET Native, none of them support MSIL features required by F#.
Likewise .NET Core only accounted for C# and VB.NET, and they are still reimplementing type providers and the REPL for it.
Finally after all these years F# still lacks tooling for Forms, WPF and EF.
Meanwhile C# keeps getting some F# features.
Currently F# is being positioned as a language for data science with its type providers and Azure Netbooks.
I don't think there are any languages out there outside of Rust (which has it's own niche since Swift is ARC and Rust is more or less manual) that does the same.
F# should get a bit more love by Microsoft.
Plenty of GC books describe such algorithms, including the canonical "The Garbage Collection Handbook".
All the languages I referred do compile to native code as well. So you can also check the generated Assembly, just like with C.
They also do provide ways of doing C pointer style tricks, use value type allocations or manual memory management.
Then there is ATS and ML Kit as well.
As language greek I do like Swift, but it isn't really meaningful outside Apple's ecosystem.
Most of the iOS platform libraries are only available in Objective C and Swift.
Most of the Android platform libraries are only available in Java (or other JVM languages).
Also when the platform vendor makes changes, you have to wait for the cross platform solution to catch up.