-
Notifications
You must be signed in to change notification settings - Fork 234
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
feat(AztecMacro): Let function convey mutability #6078
Comments
Love the idea! I think it is needed but I wonder if there is a better name? I feel like the name should align with whatever is used on AztecjS side |
Nice. Would it be possible to limit static (contract) methods to only (external) call other static methods at compile time? |
@fcarreiro it is very tricky to do at compile time since we don't have "storage modification opcodes", we just push stuff to the context inputs. However the way I've implemented it in #6338 only generates "Static" versions of the |
Closes #6078 Introduces the `#[aztec(view)]` (open to different naming, @spalladino @rahul-kothari ) modifier to functions, that forces them to be executed in an static context. It also forces generation of a "static only" `CallInterface` for them, trying to spare users from making regular calls to them. ~~Need input from the AVM team (@dbanks12 @fcarreiro) on how to implement the concept in the AVMContext.~~ In order to support direct simulated calls to view functions, the simulate method has been modified to go through the account entrypoint, which has led to implementing retrieval of return values through the whole callstack instead of just taking the latest one. Also adds the ability to navigate from contract interfaces to their implementations via LSP! --------- Co-authored-by: dbanks12 <david@aztecprotocol.com>
Closes #6078 Introduces the `#[aztec(view)]` (open to different naming, @spalladino @rahul-kothari ) modifier to functions, that forces them to be executed in an static context. It also forces generation of a "static only" `CallInterface` for them, trying to spare users from making regular calls to them. ~~Need input from the AVM team (@dbanks12 @fcarreiro) on how to implement the concept in the AVMContext.~~ In order to support direct simulated calls to view functions, the simulate method has been modified to go through the account entrypoint, which has led to implementing retrieval of return values through the whole callstack instead of just taking the latest one. Also adds the ability to navigate from contract interfaces to their implementations via LSP! --------- Co-authored-by: dbanks12 <david@aztecprotocol.com>
Closes AztecProtocol/aztec-packages#6078 Introduces the `#[aztec(view)]` (open to different naming, @spalladino @rahul-kothari ) modifier to functions, that forces them to be executed in an static context. It also forces generation of a "static only" `CallInterface` for them, trying to spare users from making regular calls to them. ~~Need input from the AVM team (@dbanks12 @fcarreiro) on how to implement the concept in the AVMContext.~~ In order to support direct simulated calls to view functions, the simulate method has been modified to go through the account entrypoint, which has led to implementing retrieval of return values through the whole callstack instead of just taking the latest one. Also adds the ability to navigate from contract interfaces to their implementations via LSP! --------- Co-authored-by: dbanks12 <david@aztecprotocol.com>
Closes AztecProtocol/aztec-packages#6078 Introduces the `#[aztec(view)]` (open to different naming, @spalladino @rahul-kothari ) modifier to functions, that forces them to be executed in an static context. It also forces generation of a "static only" `CallInterface` for them, trying to spare users from making regular calls to them. ~~Need input from the AVM team (@dbanks12 @fcarreiro) on how to implement the concept in the AVMContext.~~ In order to support direct simulated calls to view functions, the simulate method has been modified to go through the account entrypoint, which has led to implementing retrieval of return values through the whole callstack instead of just taking the latest one. Also adds the ability to navigate from contract interfaces to their implementations via LSP! --------- Co-authored-by: dbanks12 <david@aztecprotocol.com>
Closes AztecProtocol/aztec-packages#6078 Introduces the `#[aztec(view)]` (open to different naming, @spalladino @rahul-kothari ) modifier to functions, that forces them to be executed in an static context. It also forces generation of a "static only" `CallInterface` for them, trying to spare users from making regular calls to them. ~~Need input from the AVM team (@dbanks12 @fcarreiro) on how to implement the concept in the AVMContext.~~ In order to support direct simulated calls to view functions, the simulate method has been modified to go through the account entrypoint, which has led to implementing retrieval of return values through the whole callstack instead of just taking the latest one. Also adds the ability to navigate from contract interfaces to their implementations via LSP! --------- Co-authored-by: dbanks12 <david@aztecprotocol.com>
Currently it is not possible for a function to convey to other contracts, that it will not be manipulating state, e.g., that it should be called using a
static_call
.It is currently the burden of the caller, to do a
static_call
when needed, instead of acall
.This means that for contract such as a token, other contracts that need to fetch a balance on that token, must explicitly use a
static_call
instead of having the interface it uses know that it should be static, if the contract was defined asAllowing this data to be easily conveyed makes it much less error prone to build on top, as it is now just required to remember the
static
at the interface, instead at every time you will make a call.If a call is made to some user provided "token", and it is not
static
pain ensures as it could really be calling anything, and the control flow is passed on.The text was updated successfully, but these errors were encountered: