Skip to content
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

[Feature] Explore hiding async functions #28531

Open
vicsn opened this issue Mar 17, 2025 · 1 comment
Open

[Feature] Explore hiding async functions #28531

vicsn opened this issue Mar 17, 2025 · 1 comment
Labels

Comments

@vicsn
Copy link
Collaborator

vicsn commented Mar 17, 2025

🚀 Feature

It might be possible to get rid of async function calls at the leo level. This needs a comprehensive security analysis before starting a PoC. We need to know whether we're not losing essential expressivity with regards to how developers can order their async calls to be executed.

For example, the following code:

mapping account: address => u64;

record token {
    owner: address,
    amount: u64,
}

async transition mint_public(
        public receiver: address,
        public amount: u64,
    ) -> (token, Future) {
        return (token {
            owner: receiver,
            amount,
        }, update_state(receiver, amount));
    }

    async function update_state(
        public receiver: address,
        public amount: u64,
    ) {
        let current_amount: u64 = Mapping::get_or_use(account, receiver, 0u64);
        Mapping::set(account, receiver, current_amount + amount);
   }

Could instead be represented as:

mapping account: address => u64;

record token {
    owner: address,
    amount: u64,
}

transition mint_public(
    public receiver: address,
    public amount: u64,
) -> token {
    let current_amount: u64 = Mapping::get_or_use(account, receiver, 0u64);
    Mapping::set(account, receiver, current_amount + amount);
    return token {
        owner: receiver,
        amount,
    };
}
@vicsn vicsn added feature A new feature. syntax-sugar labels Mar 17, 2025
@alexanderkim11
Copy link

This would be very nice from a readability perspective and for lowering the barrier to entry for newer Leo devs. Two questions/concerns off the top of my head:

  1. I'm assuming that the async/Future model would still remain in place in Aleo instructions. In that case, what would be the steps for assigning operations to the off-chain vs on-chain portions? Would the compiler only assign mapping operations to the on-chain section and leave the rest off-chain?

  2. There might some issues with loss of granularity in terms of users being able to choose exactly which operations execute on-chain vs off-chain. I can't think of any immediate reasons why this would be important, but it's probably worth asking

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants