Approaches to Type Erasure in Swift (2020)
fabernovel.github.iohttps://github.com/apple/swift-evolution/blob/main/proposals..., if accepted, should make most of this type of ceremony unnecessary.
Exactly, type erasure has always been a giant pain for Swift but the team has short term plans for obviating it soon.
I think sometimes people forget that Swift is still a relatively new (late 2014, ~7 years old) language. Given its scope and sizable feature set, it's no surprise there are many kinks to work through. Fortunately the team has been cruising and it gets more solid every year.
Right now it's a de facto for iOS and there's a nascent but passionate server community, give it a few more years and I think it'll be a much more attractive for things outside of iOS.
> give it a few more years and I think it'll be a much more attractive for things outside of iOS.
I would like for this to be the case, but I'm not so confident. Even a few years ago, you had corporate investment in the form of Kitura and S4TF. Now you have a few small open source projects.
The language itself is ready, but the tooling is just not there. I think the main obstacle is the lack of investment in cross-platform support by the core team. Until I can `apt-get install swift` I don't have much confidence it can gain adoption outside of the Apple ecosystem.
This is on the money. Tooling and cross platform ecosystem are a big reason I moved to Rust/Go for my server side needs.
A tar ball of something that can run on Ubuntu is simply not good enough.
Yeah I 100% agree that the tooling is not there outside of macOS.
That being said, it started as geared towards iOS/macOS & even so there have been decent cross platform wins (linux compiler support is pretty solid, SPM).
I hope that as the language matures the language features that have been the priority on the roadmap (async/await, generics, memory management) will give way to more cross platform tooling.
The language also had some false starts (in 1.0 / 2.0) and some interoperability baggage (with ObjC). But arguably, it is in a steady path now. If Apple continue the current path, in 3 or 4 years, it will be much more interesting.
Of course, in our industry, whether anything can continue the current path for another 3 or 4 years is a big unknown itself.
If they allowed a bit more dynamism they could make protocols using Self existential too, right?
I know Swift is all about “as static is possible”, but maybe some explicit “dynamic” notation when you want to use Self-using protocols as a type could work.
That what this proposal should cover. AFAIK there have never been an intention to limit existential for the sake of making the language more static; rather, it was born out of technical limitations of Swift compiler in the past.
To dissuade people from using existentials by default, the ongoing discussion focuses on requiring 'any' keyword in an existential type declaration.