Compiling Swift Generics [pdf]
download.swift.org
download.swift.org
What surprised me most so far, again having only read a portion so far, is the caveats around crossing module boundaries for analysis. I’ve been, frankly, surprised at how much this is expressed as a difficulty in far more dynamic environments like JS ESM, but where the module boundaries not always totally static but in practice almost always are. I’d expect that a much more static and controlled environment like Swift would not have so many challenges in that area. But maybe this is a misconception of how static Swift actually is? Probably so!
Adding this comment with more ignorance than insight mostly in hopes I come back to see more knowledgeable discussion when I return.
To get additional background, you might be interested in this[0] conference talk (the paper's author is one of the co-presenters). Also, this post[1] by a Rust and Swift compiler engineer talks about what Swift does differently than other languages, and the tradeoffs that are involved.
The part about module boundaries is what allows separately-compiled and updated shared libraries to work (like the frameworks in the OS). There’s an @inlinable attribute to publish a function’s body to clients, but then if you update the library it won’t be picked up until clients are recompiled (which might be fine, for example a lot of standard library collection algorithms and so on are inlinable).
As you know so many of Apple's frameworks are packaged as shared libraries, and enabling them to export generic definitions which operate on concrete representations would be killer.
It may be the only “niche” language that bubbles to the higher levels of preference polls.
One reason that Apple is an attractive target platform, is because it’s fairly lucrative.
I've been using a lot of swift lately and it's one of the most expressive (and impressive) language of late.
I've been blown away by its terseness which leads to incredible functionality (SwiftUI is basically a DSL[1]) and robustness of the type system.
When it compiles, it will most likely not crash, unless I specifically said "doing!yolo-dumb!stuff!here".
I'll come out and say it, Swift might be the most advanced high-level language in terms of power vs. UX.
I'll also say that its compile messages, half the time, are like academia vomit thrown at the face of the developer -> that needs to improve.
[1] (which agreeably leaks a bit)
But considering the DSL is fully statically typed, wow.
So it's a bit of give and take on that one.
Amusingly, using other languages now, I'm finding I'm missing the implied nature of Swift at times.
The main issue with Swift as a general language is that the standard library is not broadly enough designed, and the language is very tied to the standard library. It’s hard to see Swift being used to write an OS kernel, or even a Linux kernel module, for example. Swift is an application language for Apple platforms, and it will remain so until someone puts effort into making it otherwise.
That said, the new regex facilities in Swift 6 make it a real contender for scripting tasks where you might otherwise consider using Ruby / Perl / Python. So there is progress.
I do worry about its future however: dual-native mobile apps are less and less popular with product owners with every passing year, the market seems to be moving to flutter. Which is a pity! It's such a great language.
Given what we've all been reading lately about Google's LPA cycle (launch, get promoted, abandon) it seems likely that flutter will end up like React Native: kinda usable, but never really polished enough, it seems they just stopped most work on it before the finish line.
It's a niche language because the marketing of it to non-Apple-platform developers over the years has totally bombed, and it has close to zero mindshare amongst them.
(People who were already Apple-platform developers playing around with hosting a webapp on a Linux box don't count)
Hopefully I'll get used to it. It does seem like all this serves a purpose, perhaps more readable as a result, but it seems to take more writing than I'm used to in python / go / rust.