Compiler attribute to guarantee that types are trivially encodable/decodable

[xunilrj]

Contract functions can gain a lot of performance if their inputs are trivially decodable, but today there is no easy way for a developer to check if a type is "trivially decodable" or not. And there is not way to fail compilation if a type is not, possibly causing silent regressions.

This issue is a suggestion for create an attribute that would force the compiler guarantee this:

#[trivial_decode]
struct ComplexType {
    ...
}

The idea is to make the compilation fail, if ComplexType is not trivially decodable.
For completeness we would have both attributes:

1 - trivial_decode;
2 - trivial_encode;

Another improvement would be to have performance hints analysing ABIs and suggesting that types should be trivial encodable and decodables. To turn these off, we would need:

#[allow(not(trivial_decode))]

[ironcev]

Here are additional elements to consider for the completeness of the proposal:

• attributing the usage sites (entries, logs) along with the types.
• if we are attributing the usage sites, having the opportunity to override trivial, i.e. allow non-trivial, types on certain entries.
• the final definition of the attribute.

Attributing on entries

Marking types as trivial definitely makes sense. But in majority of cases, I expect developers to be interested more in being able to express something like: "All the contract methods of this contract must use trivial types, except some_rfc_method where the type is given by the RFC and unfortunately not trivial."

Starting from the boundaries also looks like a more natural way of thinking to me. Like: "All the boundary types in this contract methods must be trivial", rather than "This type I will use on a boundary so I'll mark it as trivial."

Marking types as trivial I see more in library development.

If we want to support attributes on usage sites, we can allow them on contracts and main entries. Something along these lines:

contract;

#[trivial_decode, trivial_encode]
impl Contract {
   // All params and return types must be trivial.
}

script/predicate;

#[trivial_decode, trivial_encode]
fn main(...) -> ... {
   // All params and return types must be trivial.
}

For contract, we can add it on individual methods only:

contract;

impl Contract {
   #[trivial_decode, trivial_encode]
   fn i_am_fully_trivial(...) -> ...;

   #[trivial_decode]
   fn i_am_only_trivial_decode(...) -> ...;

   fn i_can_be_trivial(...) -> ...;
}

Being able to remove triviality if the whole contract is trivial is than also useful:

contract;

#[trivial_decode, trivial_encode]
impl Contract {
   fn i_am_fully_trivial(...) -> ...;
   fn i_am_also_fully_trivial(...) -> ...;

   #[not_trivial_decode, not_trivial_encode]
   fn i_could_be_trivial_but_must_not(...) -> ...;

   #[not_trivial_decode]
   fn i_am_trivial_encode_but_must_not_be_decode(...) -> ...;
}

Attributing on logs

I don't see at first how this could be done in code, nor that it would be practical. Having, e.g., a build option to force it also doesn't feel as the best option.

Maybe simply accept that this is done by attributing logged types in the combination with the hints analysis as proposed in the issue description.

Most of the logged types are events, so knowing marking events as #[trivial_...] can be a well established practice.

Attribute definition

What about #[trivial(encode, decode)]?

It looks to me:

• less verbose
• fits better into existing set of attributes like #[storage(read, write)] or #[inline(always)].

Also, it allows us to use only #[trivial] as a shortcut for #[trivial(encode, decode)].

So we can have:

• #[trivial]
• #[trivial(encode)]
• #[trivial(decode)]
• #[trivial(encode, decode)]

Expressing allowing non-triviality could than also be done with an argument instead of having a separate attribute:

• #[trivial(optional)]: both trivial encoding and decoding is optional.
• #[trivial(encode, optional)]: trivial encoding is optional, decoding inherited.
• #[trivial(decode, optional)]: trivial decoding is optional, encoding inherited.
• #[trivial(encode, decode, optional)]: both trivial encoding and decoding is optional.
• #[trivial(encode, optional), trivial(decode)]: trivial encoding is optional, decoding mandatory.

[xunilrj]

We can also use the "value" of attribute arguments...

#[trivial(encode = "optional", decode = "any")]

With possible values:

• any: the default value. The compiler doesn't do anything.
• optional: Compiler will warn if it is not trivial.
• required: Compiler will error if it is not trivial.

For Contracts

When checking the implementation of a contract, the compiler will search for this attribute in the following order:

#[trivial(decode = "required")]                // 5
struct Argument { ... }

#[trivial(decode = "required")]                // 4
abi SomeAbi {
    #[trivial(decode = "required")]            // 3
    fn some_fn(arg: Argument);
}

#[trivial(decode = "required")]                // 2
impl Contract for SomeAbi {
    #[trivial(decode = "required")]            // 1
    fn some_fn(arg: Argument) {
        ....
    }
}

If you control everything, the easiest thing should be to decorate the ABI definition and opt-out functions when needed.
If you control anything, you can still have fine control over decorating the implementation.

[ironcev]

Agree! Using the attribute arguments like trivial = "optional" is more idiomatic than trivial optional.

Also, by using "any" devs can overload the inherited value and remove errors and warnings if wanted. This removes the need for #[allow(not(trivial_decode))].