Open kulikthebird opened 5 months ago
On the one hand this is directly connected to the types used by the contracts entry points so it could be defined inside entry_points
macro.
On the other it would be great to expose those types as they most likely will be tested by the user and all the multitest helpers are generated by the contract
macro.
I think we could move the generics to some attribute (I don't see a good name for it at the moment) and then use it in the contract
and entry_points
.
In such case entry_points
macro should emit_error
in case the contract is generic and attribute is not present.
Let's consider macro-generated types aliases for a contract's strucutre along with
ContractExecMsg
,ConractSudoMsg
,ContractQueryMsg
andInstantiateMsg
. This might be useful when the contract structure is generic. Eventhough it's generic, the entrypoints must use only a single monomorphisation of that structure e.g.:#[contract]
or#[entry_points(generics<SomeCustomMsg, SomeCustomMsg>)]
could introduce the following type aliases:Those aliases could be used in at least two contexts:
CodeId<Contract>
requires specifying the contract type. It might be useful to use aliases instead of adding the generic types each time the testswrite_api!
macro requires to specifyContractExecMsg
,ContractQueryMsg
andContractSudoMsg
structures with all the generics that were specified in the entry_points macro. That can be automated and protect contract devs from specyfying different generic types by mistake.On top of that a new macro
sv_write_api!
could be implemented to remove the boilerplate code in schema generating code: