A Vision for WebAssembly Support in Swift #2590
Conversation
Co-authored-by: Yuta Saito <[email protected]>
Co-authored-by: Ben Barham <[email protected]>
Co-authored-by: Alex Hoppen <[email protected]>
Co-authored-by: Alex Hoppen <[email protected]>
Co-authored-by: Hamish Knight <[email protected]>
Co-authored-by: Alastair Houghton <[email protected]>
| Preliminary support for WIT has been implemented in | ||
| [the `wit-tool` subcommand](https://github.com/swiftwasm/WasmKit/blob/0.0.3/Sources/WITTool/WITTool.swift) of the | ||
| WasmKit CLI. Users of this tool can generate `.wit` files from Swift declarations, and vice versa: Swift bindings from | ||
| `.wit` files. |
There was a problem hiding this comment.
This is a great introduction, thanks @MaxDesiatov
| (2) The new [shared-everything-threads](https://github.com/WebAssembly/shared-everything-threads) proposal is still | ||
| in the early stages, but is expected to be the future of multi-threading in Wasm. | ||
|
|
||
| Swift currently supports two threading models in Wasm: single-threaded (`wasm32-unknown-wasi`) and multi-threaded |
There was a problem hiding this comment.
aside: should we consider changing the wasm triple to match other languages? (specifically rust's changes here would also make sense for swift https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html)
There was a problem hiding this comment.
This was partially done by @kateinoigakukun, at least for the threads triple.
There was a problem hiding this comment.
Agree. "Officialization" would be a good opportunity to rename the target name.
Co-authored-by: Danielle <[email protected]>
| cooperation from the WebAssembly toolchain side or different memory layout in Swift metadata to support 64-bit linear | ||
| memory support in WebAssembly. | ||
|
|
||
| ### Shared libraries |
There was a problem hiding this comment.
A few of us recently hashed out a design for supporting a more dynamic approach to shared libraries in the component model. Based on that sketch, I think it's reasonable to assume that we'll have something similarly expressive as traditional dlopen for shared libraries in the component model.
rjmccall
added
vision
No description provided.