[to be discussed] lang: macro that calculates type size at compile time

[paul-schaaf]

TO BE DISCUSSED

Problem

space calculation via derive(Default) is gone in favour of size declarations at compile time.

This adds a little bit of work for users because they have to specify size in init even for types that are not dynamic.

Solution

derive(size) macro on types which expand into an impl with a const variable that defines the type's size by reading its inner types' lengths.

#[derive(size)]
pub struct MyData {
   pub value: u64,
   pub other_value: u8,
   pub authority: Pubkey
}

would result in the following added code:

impl MyData {
    pub const SIZE: usize = 8 + 1 + 32;
}

[Henry-E]

This would be much appreciated.

Perhaps there could also be an additional macro to indicate the maximum length of a dynamic type.

e.g.

#[derive(size)]
pub struct MyData {
   pub value: u64,
   pub other_value: u8,
   pub authority: Pubkey,
   #[max_len = 10]
   pub this_seed: Vec<u8>
}

impl MyData {
    pub const SIZE: usize = 8 + 1 + 32 + 10;
}

Naturally it's also important that this be able to work recursively for structs containing custom types.

e.g.

#[derive(size)]
pub struct MyData {
   #[max_len = 10]
   pub custom_accounts: Vec<CustomAccount>
}

#[derive(size)]
pub struct CustomAccount {
   pub value: u64,
   pub other_value: u8,
}

impl MyData {
    pub const SIZE: usize = 10 * ( 8 + 1);
}

[Arrowana]

If it works for the most common dynamic length type Vec but also work out of the box for Option<T> that would be nice.

Another request, can we make this happen by default on the #[account] macro at the top and bail to ask user to implement SIZE/LEN or add more macro on specific fields? But then we might have issues with size definition in nested structs...

[callensm]

this feature is now much harder to achieve consistently since the introduction of account space reallocation. static assertions on dynamic type sizing isn't feasible anymore and the data fields within an account struct are no longer indicative of the actual space allocated to the account.

[armaniferrante]

This would have to refer not to the account's data slice size, but to the minimum size to required to store the type, which would still help for things like default space allocation.

[callensm]

This would have to refer not to the account's data slice size, but to the minimum size to required to store the type, which would still help for things like default space allocation.

i guess thats true. once the account has been initialized with the default space allocation, the default space calculation isn't very relevant afterwards. could be misleading if people use it for data size comp filters on program account reads though.