`self` mutability in the account methods in the script

[greenhat]

Problem

We don't have the information regarding the mutability of self in the account methods in the script.

Context

All the account components with bindings generated as free functions in the modules are gathered under the Account as struct methods.

Why self mutability info missing?

TLDR; The bindings are generated from the WIT interface which has no notion of self (it's just a bunch of functions) and therefore its mutability.

Let's take the basic-wallet example.

From the user's code with proper &mut self at

compiler/examples/basic-wallet/src/lib.rs

Lines 14 to 38 in adfb610

	#[component]
	impl MyAccount {
	/// Adds an asset to the account.
	///
	/// This function adds the specified asset to the account's asset list.
	///
	/// # Arguments
	/// * `asset` - The asset to be added to the account
	pub fn receive_asset(&mut self, asset: Asset) {
	self.add_asset(asset);
	}
	/// Moves an asset from the account to a note.
	///
	/// This function removes the specified asset from the account and adds it to
	/// the note identified by the given index.
	///
	/// # Arguments
	/// * `asset` - The asset to move from the account to the note
	/// * `note_idx` - The index of the note to receive the asset
	pub fn move_asset_to_note(&mut self, asset: Asset, note_idx: NoteIdx) {
	let asset = self.remove_asset(asset);
	output_note::add_asset(asset, note_idx);
	}
	}

The #[component] macro generates the WIT interface:

// This file is auto-generated by the `#[component]` macro.
// Do not edit this file manually.

package miden:basic-wallet@0.1.0;

use miden:base/core-types@1.0.0;

interface basic-wallet {
    use core-types.{asset, note-idx};

    receive-asset: func(asset: asset);
    move-asset-to-note: func(asset: asset, note-idx: note-idx);
}

world basic-wallet-world {
    export basic-wallet;
}

From which the wit-bindgen::generate! macro generates bindings (free functions in a module):

pub mod bindings {
    pub mod miden {
        pub mod basic_wallet {
            pub mod basic_wallet {
                pub fn receive_asset(asset: ::miden::Asset) -> () {
                    ...
                }
                pub fn move_asset_to_note(asset: ::miden::Asset, note_idx: ::miden::NoteIdx) -> () {
                    ...
                }
            }
        }
    }

Then, we generate methods for the Account from the functions above.

There is no notion of self in the WIT and therefore in the generated bindings.

Solutions

Explore the Wasm CM resources to represent an account component. See an intro to resources at https://component-model.bytecodealliance.org/language-support/using-wit-resources/rust.html

The resource has self in the generated Rust bindings and has borrow as well as write and read attributes in the WIT for the resource methods.

AFAIR, the Wasm CM resource uses call_indirect in the compiled code so it might be the time for us to implement it.

[greenhat]

#788 is related but it is for the self mutability on the account side.

[greenhat]

@bitwalker @bobbinth As a temporary workaround I generate all account methods with &mut self in the Account struct established at #798

[bobbinth]

I'm assuming there is no easy way to attach some kind of metadata to WIT interface, right?

Differentiating between mutating and non-mutating methods of an account would be important because only non-mutating methods are available for FPI calls. So, when we get to generating account wrappers that can be used to facilitate FPI calls, we'll need to be able to figure out which methods to select based on whether they are mutating or not.

[greenhat]

I'm assuming there is no easy way to attach some kind of metadata to WIT interface, right?

No, there is not. I have high hope for the Wasm CM resources. If for some reason the resources will not fit we can explore encoding the mutability in the interface in some hacky way either by splitting the interface in two (mutable vs immutable) or encoding mutability in the function name. I'd do it as the last resort only.

Differentiating between mutating and non-mutating methods of an account would be important because only non-mutating methods are available for FPI calls. So, when we get to generating account wrappers that can be used to facilitate FPI calls, we'll need to be able to figure out which methods to select based on whether they are mutating or not.

Got it. Makes sense.