Also add the capability to support for bit filed or other underlying POD functionals.
lygstate opened this issue · 6 comments
Such as char,uchar,int8,int16,int32,int64 and so on?
Also pack are needed:)
As the README says, this proposal aims to be minimal, and since packing and sized fields are not required by either a minimal WasmGC interop machinery nor concurrency, they are not included. Incremental steps!
As the README says, this proposal aims to be minimal, and since packing and sized fields are not required by either a minimal WasmGC interop machinery nor concurrency, they are not included. Incremental steps!
Hi, at least a extension point for this need preserved:)
FFI or WASM interop would benefit from this:)
https://github.com/ffi-cross/js-ffi-cross
Yep, my intention is to preserve an extension point so programmers can choose the representation of fields in the future.
FFI or WASM interop would benefit from this:)
I think FFI is a separate problem than choosing the representation and packing in-memory layout of structs. FFIs need predictable marshalling that you can tie to a particular type, and that problem can be solved orthogonally to the one of in-memory representation.
FFI or WASM interop would benefit from this:)
I think FFI is a separate problem than choosing the representation and packing in-memory layout of structs. FFIs need predictable marshalling that you can tie to a particular type, and that problem can be solved orthogonally to the one of in-memory representation.
Yeap, does this proposal would have predictable marshalling? maybe using
https://github.com/tc39/proposal-decorators
Yeap, does this proposal would have predictable marshalling? maybe using
Similarly, marshalling and solving for FFI is explicitly out of scope for this minimal proposal and is intended to be explored in the future as an extension on top.