You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the support for the CustomQuery and CustomMsg we can define chain specific Contracts and Interfaces.
We should also add support for generics to allow chain generic Contracts and Interfaces to work with custom queries and messages.
Expand current generic support for interface macro
Interface macro should parse bounds defined on trait and generate messages with them. We should keep current CheckGenerics functionality to filter generics used for execute and query messages for API clarity.
Also generics are currently not used in case of features like Querier and should be propagated everywhere needed.
It might be that in current shape cosmwasm_schema::QueryResponesreturns attribute does not support generic return type. It has to be checked and if needed implemented in cosmwasm-schema.
Otherwise it should be an easy task. Parsing return type in CheckGenerics should do the trick.
Because generic param in message structure will be used only in #[returns] attribute it will fail to compile with generic unused error. Most likely we will have to generate phantom variant for that, possibly with std::convert::Infallible.
It would be an inconvinience for the user to track which generic params are used with which message. Especially once new messages would be introduced to the Interface there would be a need to reevaluate which generic params should be added to which messages.
To avoid this issue we will introduce sylvia::Interface trait which will hold interface message types.
pubtraitInterface{typeExec;typeQuery;}
interface macro will then generate struct generic over params used by the user and implement this Interface trait on it.
It should look something like this:
Now that we have support for generic interface and also Interface helper type generated we can allow user to implement it on the Contract. Thanks to Interface helper type we don't have to use the current implementation and we will just require user to provide all generic types in messages attribute.
In case of implementation Interface on Contract we should be able to avoid adding generic types in messages attribute as we will be able to extract them from impl block structure.
Behavior should not change here and forwarding generic attributes from messages should work the same as in case of a single generic interface.
The only issue might appear in ContractExecMsg and ContractQueryMsg generation. Here proper test has to show that generics are properly concatenated
Support generics on Contracts
User might want to define the Contract to store some generic data. We should support this case.
We should use CheckGenerics functionality here to block generics from being forwarded to generated messages and use these generics only when reffering to Contract in generated code.
entry_points cannot have generic types so we have to generate them with solid types.
It's required only by entry_points so we can it as param to this macro. This types refer to generics defined on Contract not Interface.
Could you add example usages of the new messages form?
In general, please provide examples of how you expect API to look like when:
The contract type is generic. Note that you need to provide generic types to be used for the contract in entry points - there is a question if you provide them as part of #[contract] or #[entry_points]
The interface is generic but is implemented on non-generic contract
The interface is generic and is implemented on a generic contract
Also, examples of using generics as the custom msgs/queries should be here. For now, the #[messages(my::module: exec(Msg: msg + bonds), query(Param: query + bonds)] looks very suspicious to me - anything that is generic should look like generics, what is type bound should most likely look like type bounds. However, I cannot be sure unless I see the proposed usage.
Before starting the implementation, we should have confirmed the API we want to achieve.
One comment about entry points - they cannot be generic at the end of the day. There has to be concrete monomoprhisation to be called in the entry points. I would see #[entry_points<Generic, Arguments>] form for generic contracts.
With the support for the
CustomQuery
andCustomMsg
we can define chain specific Contracts and Interfaces.We should also add support for generics to allow chain generic Contracts and Interfaces to work with custom queries and messages.
Expand current generic support for
interface
macroInterface
macro should parse bounds defined on trait and generate messages with them. We should keep currentCheckGenerics
functionality to filter generics used forexecute
andquery
messages for API clarity.Also generics are currently not used in case of features like
Querier
and should be propagated everywhere needed.Generic return type
It might be that in current shape
cosmwasm_schema::QueryRespones
returns
attribute does not support generic return type. It has to be checked and if needed implemented incosmwasm-schema
.Otherwise it should be an easy task. Parsing return type in
CheckGenerics
should do the trick.Because generic param in message structure will be used only in
#[returns]
attribute it will fail to compile withgeneric unused
error. Most likely we will have to generate phantom variant for that, possibly withstd::convert::Infallible
.Unfortunately this approach will pollute schema.
Create trait to track message types of interface
While implementing Interface on Contract there is a need to distinguish
exec
andquery
generics. It would mean that our API would look like this:It would be an inconvinience for the user to track which generic params are used with which message. Especially once new messages would be introduced to the Interface there would be a need to reevaluate which generic params should be added to which messages.
To avoid this issue we will introduce
sylvia::Interface
trait which will hold interface message types.interface
macro will then generate struct generic over params used by the user and implement thisInterface
trait on it.It should look something like this:
Implement generic interface on contract
Now that we have support for generic interface and also
Interface
helper type generated we can allow user to implement it on the Contract. Thanks toInterface
helper type we don't have to use the current implementation and we will just require user to provide all generic types inmessages
attribute.In case of implementation Interface on Contract we should be able to avoid adding generic types in
messages
attribute as we will be able to extract them fromimpl
block structure.Implement multiple generic interfaces on contract
User might want to implement multiple Interfaces on the Contract. In such case generic types will also be provided via
messages
attribute.Behavior should not change here and forwarding generic attributes from
messages
should work the same as in case of a single generic interface.The only issue might appear in
ContractExecMsg
andContractQueryMsg
generation. Here proper test has to show that generics are properly concatenatedSupport generics on Contracts
User might want to define the Contract to store some generic data. We should support this case.
We should use
CheckGenerics
functionality here to block generics from being forwarded to generated messages and use these generics only when reffering toContract
in generated code.User might also want to generate generic contract messages.
Implement non-generic Interface on generic Contract
Below example should not require any additional work.
ContractQueryMsg<T>
should be able to "dispatch message further" to the Interface.Entry points
entry_points
cannot have generic types so we have to generate them with solid types.It's required only by
entry_points
so we can it as param to this macro. This types refer to generics defined on Contract not Interface.Basing on that macro should generate something like this:
Update docs
Describe usage of generics in
sylvia-book
andREADME
.Tasks split
The text was updated successfully, but these errors were encountered: