-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More generic encoding for complex return value #602
Comments
Interesting investigation, but I don't think this is much of a pain point - it works, and I don't think we add any more complex FFI types soon. Happy to revisit this if we have actual use cases that need larger return types (and maybe just leave the next iterator as is anyway to avoid breaking compatibility). But it would be cool to have a better struct if we need to return more. |
I looked into Ethereum's RLP but this is too complicated because of the nesting which we do not need. A flat list of binary values is sufficient. |
I now realized that the length as a suffix is only needed because we use So instead of |
Do not start this before #504 is merged. Otherwise big merge mess ahead. |
This is API breaking for the Storage iterator, correct? I think we should start labeling API Breaking changes, and start moving them to CWIPs. (Not saying we need the full process here, but let's start some process/custom for labeling these. I will make a few API breaking proposals soon as well) |
It breaks the contract-VM interface (binary compatibility), not the standard librarie's API (source compatibility). I completely agree moving the result of this long thread into a CWIP. |
Do you still want to do this? For me it would be good to get it in the next release as there are quite a few breaking changes already. Or decide not to do it at all. It would be good to get these apis quite stable soon |
Yes. It is not hard and clear now. I think it makes sense to work that out when starting with the crypto APIs, which will touch this whole contract-VM interface a lot. |
Fair enough |
In the
db_next
import, we currently use a custom encoding to return two values (key and value). This is okay for now but not the nices thing you can imagine when developing a rich API via imports.I tried to use Wasm multiple return values, which is more or less this diff:
Returning two pointers makes the code much nicer. However, this fails to link.
As you can see in
expected: FuncSig { params: [I32, I32], returns: [] }
, this compiles to a Wasm function with 2 arguments and no return value. It is unclear if multiple return values in imports are supported by the Rust compiler (see e.g. rust-lang/rust#47599).If we are stuck with FFI types, we might want to use a more generic encoding schema than
value || key || keylen
, which at least supports more than two values.The text was updated successfully, but these errors were encountered: