-
Notifications
You must be signed in to change notification settings - Fork 426
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
contract_ref!
produces traits with too strong requirements
#1868
Comments
I agree that we don't need to require a But on the other side, it adds clarity to actions. When you call the The problem comes when you want to store It is possible to alter the trait/method by the ink macro during definition and replace all I prefer to avoid that and keep things simple in a Rust way. A clone of the |
I don't think the knowledge of whether the method mutates the called contract or not is useful in more ways than simply theoretical. I doubt SC authors care about that. Even if the call is potentially dangerous (reentrancy attack) it can still be read-only (non-mutable). SC calling is too different from "normal Rust" for it to matter IMHO. If you think it's too much work or would add too much "magic" (and/or gotchas) then these arguments convince me more than the one about having assumptions in the type-system. |
Since
contract_ref!
macro produces the "access trait" with the exact same method signatures as the ones on the original contract, sometimes it puts too strong of requirements onself
on the caller's side.Consider the following case:
compiler requires that
psp22_ref
ismut
becausePSP22::transfer(&mut self, ...)
. Even though it should not be necessary on the call side sincepsp22_ref
is just an address and not an actual contract state.The text was updated successfully, but these errors were encountered: