A Vision for WebAssembly Support in Swift #2358
Conversation
| Despite its origins in the browser, it is a general-purpose technology that has use cases in client-side and | ||
| server-side applications and services. WebAssembly support in Swift makes the language more appealing in those settings, | ||
| and also brings it to the browser where it previously wasn't available at all. | ||
|
|
There was a problem hiding this comment.
I think it would be nice to say (or organize sections)
- The current state of the WebAssembly Support
- What does WebAssembly Support bring to the language
- What kind of language evolutions will be needed or what is the current missing piece
(I'm not sure if we really need Wasm-specific language evolutions)
There was a problem hiding this comment.
@_extern(wasm, module:, name:) might need to be formalized as an SE proposal.
There was a problem hiding this comment.
And @_expose(wasm) too 😉
There was a problem hiding this comment.
The second point is the main thing I felt was missing here. The third point could probably be part of a section after goals, ie. Language Support or something similar. I'm not sure the current state belongs in the vision, it should certainly be part of any associated forum post though.
The second seems partially answered by portability/security, but then the sections after that seem more about describing WebAssembly (and its different parts) itself. Maybe those should go under a WebAssembly Components (not quite sure if that's the right wording, especially since WebAssembly Component Model is a thing) section. So we'd have eg.
- Introduction - what you have now, but expanded a little to cover what adding support brings to Swift. This could mostly just be the portability + security sections combined into the intro + anything else you want to point out.
- WebAssembly Components - this could basically just be the two WASI/component model sections you have now, but merged together and maybe reworded slightly to link them a little more.
- Goals
- Sections for any expansion on the goals, eg. the difference pieces (including language support) that need to be added
There was a problem hiding this comment.
Thank you @bnbarham, I've addressed your feedback and added the "Goals" section, limited to 5 high-level goals for now, followed by a short "Proposed Language Features" subsection.
| This means that adoption of Wasm in developer tools does not imply unavoidable performance overhead. In fact, with | ||
| security guarantees that virtualization brings there's no longer a need to spawn a separate process for each |
There was a problem hiding this comment.
I love this sentence :)
MaxDesiatov
changed the title
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]>
| [`__attribute__((export_name("name")))`](https://clang.llvm.org/docs/AttributeReference.html#export-name), which | ||
| is the counterpart of `@_extern(wasm)` working in the opposite direction. This explicitly makes a Swift declaration | ||
| available outside of the current module, added to its exports section under a given name. Again, the lack of | ||
| this attribute in Swift requires use of C headers as a workaround. |
There was a problem hiding this comment.
I wondered if there was going to be a summary or conclusion at the end. It might be nice to have some form of wrap-up, I think.
There was a problem hiding this comment.
Not sure how that would look without tautologically rehashing what's been said in other sections. I'm open to concrete suggestions though.
Co-authored-by: Alastair Houghton <[email protected]>
|
I see this primarily as a topic for the new Platform Steering Group, but we'll look it over on the LSG as well. |
rjmccall
added
the
PSG
|
Could this also talk a little about the story re. debugging? How do we debug Swift code built on WASM? Does it matter whether we're debugging in the browser or using a separate WASM interpreter like wasmtime? Do we support attaching LLDB somehow? How are we going to deal with metadata? |
There's no debugging story, unfortunately. Some browsers had some support for source maps at some point, some rely on DWARF, some have no support for debugging other then stepping through disassembly. I'm not aware of Wasm runtimes that have special support for debugging, other than @kateinoigakukun's wasminspect. There's apparently a WebAssembly Debugging Subgroup, but they have no meeting minutes posted since 2020. |
I think, since this is a vision document, it should probably expand on what debugging should look like, or what our goal is here in that regard, and maybe a summary of what is presently possible would be useful along with some ideas about how we might make progress towards the end goal (which, presumably, is some kind of support for source-level debugging of Swift programs running on WASM)? |
For now this contains an introduction section which doesn't assume any prior knowledge of the Wasm ecosystem. It provides overview of properties of Wasm useful when applied to Swift developer tools specifically. A list of high-level goals is provided, with a short subsection for specific language features that can be proposed in the near term.