I mean, well, it actually already exists? It's been around for a long time and works pretty great, with multithreading, access to JS objects, etc. The author of the linked thread topic is the original author of it.
Writing WASM in Swift so it can only be run by a Swift runtime also misses out on a huge aspect of that “bring your language” approach to wasm. It should support enough of the spec so a current wasm binary compiled from say Go can be executed in a WASI runtime powered by Swift and vis-versa. It’s a long way to get there.
Why are they framing it as a proposal if it's done? (if this comes across as Socratic, it is unintentional, I genuinely don't understand why the author would be posting a proposal when it is done)
EDIT: My naive reading of https://github.com/swiftwasm/swift/issues is there's a lot, lot, to go. TL;DR: open from 2021, stdio FILE not available in WASILibc. Long version, filed in 2020 and open: "Pointers needed on WASILibc", "Make the toolchain work without Xcode installed", "Enable libdispatch or provide stubs for it", 2022 "canImport(Dispatch) is wrongly truthy on WASI target", "wasm lacks signal support" (broke/regression in Sept. 2024, still open)
On macOS. Works fine on Linux.
This is such an easy ask. The only thing holding it back, imo, is Apple. Can’t let the plebs bypass Xcode to develop on their Macs!
My workaround is running a container with Linux Swift installed. Of course, I’m not targeting an Apple OS so I have the flexibility.
AFAIK, they support that. https://www.swift.org/swiftly/documentation/swiftly/getting-...:
“Overview
To get started with swiftly you can download it from swift.org, and extract the package.
On macOS you can either run the pkg installer from the command-line like this or just run the package by double-clicking on it (not recommended):
installer -pkg swift-x.y.z.pkg -target CurrentUserHomeDirectory
~/usr/local/bin/swiftly init