IIP-0011: Core Move View Functions#43
Conversation
lzpap
force-pushed
the
iip-0011-core-move-view-functions
branch
from
feb5b9e to
727a814
Compare
lzpap
force-pushed
the
iip-0011-core-move-view-functions
branch
from
727a814 to
9337b94
Compare
…m/iotaledger/IIPs into iip-0011-core-move-view-functions
…ng changed Tighten the #[view] definition and rules to forbid returning references (in addition to IOTA objects). Update the compiler guidance to allow emitting warnings (SHOULD -> MAY) for unannotated view-like functions. Replace and expand the examples: the valid/invalid Move modules were overhauled with many more structs and function cases (generics, vectors, options, native functions, templates, and various illegal patterns) to demonstrate allowed patterns (immutable refs, primitive and store-only returns) and disallowed ones (mutable refs, objects by value, returns of objects or references, TxContext mutable refs, etc.).
|
|
||
| Based on the premise that global storage is solely constituted by objects in IOTA, then: | ||
|
|
||
| A _view function_ is a Move function that does not mutate any IOTA object and that returns a value, which is not an IOTA object or a reference. |
There was a problem hiding this comment.
Reading the IIP down below makes me think we can't return read-only references to objects either, is that right?
Shouldn't we allow that? Can we return read-only references of structs/pure values? If not, what is the problem with it?
There was a problem hiding this comment.
Yes, we currently disallow returning immutable references because they cannot cross the execution boundary as references. We could model this as implicitly reading the reference and returning the serialized value, but that only works for copyable types and would make &T behave like T at the API boundary, which is misleading and not sound
There was a problem hiding this comment.
they cannot cross the execution boundary as references.
by boundary you mean
a, end of the current frame (view function),
b, end of the current PTB command,
c, or end of execution, so the RPC boundary?
I suspect you meant c, but maybe I misunderstood. In this case we are at the RPC layer so we don't need to care about type abilities. You can read any object in the public ledger off-chain anyway and "copy" their content, it's just not in the move world.
In case you meant b, we will have reference passing in PTBs in the future, so making this restriction just because we don't have that feature implemented yet is not a showstopper. If you compose view functions in move code it would already work, no?
There was a problem hiding this comment.
Yes, I meant both b and c.
In case of b, if PTB reference passing will be allowed, then this is no longer a fundamental limitation, so a returned &T could be passed across PTB commands.
For c, I agree the RPC can return a serialized snapshot of the referenced value. So, for example, the RPC would read &T and expose T.
Co-authored-by: Lorenzo Benetollo <38067715+lollobene@users.noreply.github.com>
3 participants
This PR introduces the first draft for IIP-0011
Discussion #42