get fun xxx(). They typically return data extracted from storage:
Return type
The return type is inferred when omitted. Get methods follow the same behavior as functions and methods. Specifying the return type explicitly is recommended:Custom name
Use camelCase for naming.- Recommended:
get fun currentOwner() - Not recommended:
get fun get_current_owner()
get_wallet_data, as it was named in implementations.
In such cases, using get fun get_wallet_data is appropriate, even if it does not follow the camelCase convention.
Structures
When a getter returns multiple values, define a structure and return it. Using a structure is acceptable even for a single return. Field names provide explicit metadata for client wrappers, making the structure self-descriptive.lazy loading
Use lazy loading for contract storage. Prefer lazy loadStorage() instead of loadStorage(). Unreferenced fields are skipped automatically.
Parameters
Get methods can accept parameters. Parameters use the same syntax as regular functions:Stack-based execution
Any function in TVM takes its arguments from the stack and pushes return values onto it; get methods differ only in that they can be invoked off-chain. When called off-chain, a get method does not persist state changes. A getter can returnint, which is not serializable unlike intN. Returning a structure pushes each field onto the stack as a separate value. Client libraries such as Blueprint parse get method responses using a tuple reader.
Get methods do not store their names. They are identified by a method_id = crc16(name) | 0x10000, avoiding the need to store additional strings on-chain.