[HN Gopher] Approaches to Type Erasure in Swift (2020)
___________________________________________________________________
Approaches to Type Erasure in Swift (2020)
Author : Ryuuke
Score : 27 points
Date : 2021-04-26 12:17 UTC (2 days ago)
(HTM) web link (fabernovel.github.io)
(TXT) w3m dump (fabernovel.github.io)
| georgelyon wrote:
| https://github.com/apple/swift-evolution/blob/main/proposals...,
| if accepted, should make most of this type of ceremony
| unnecessary.
| joshuawright11 wrote:
| 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.
| liuliu wrote:
| 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.
| skohan wrote:
| > 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.
| indemnity wrote:
| 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.
| joshuawright11 wrote:
| 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.
| nielsbot wrote:
| 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.
| viktorcode wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-28 23:02 UTC)