Make : custom(msg, query)
in sv::messages
attribute redundant
#352
Labels
: custom(msg, query)
in sv::messages
attribute redundant
#352
#158 Introduced mechanism to convert
Response<Empty>
toResponse<SomeMsg>
. This allowed us to make implementation of the Interfaces that do not supportCustomMsg
s either because the author didn't provide theExecC
associated type for users to implement their ownCustomMsg
or because it was deliberately chosen not to allow chain specific logic via#[sv::custom(msg=Empty, query=Empty)]
attribute.We exposed this conversion via addition of
: custom(msg, query)
at the end of#[sv::messages(...)]
attribute. Provided this parametercontract
macro was able to determine that theResponse
returned from the Interfaces method has to be converted using theIntoResponse
interface and analogical thing should happen to theDeps
.Because of above we don't want to remove the conversion mechanism and rather this issue aims to find out a way to make the mechanism automatic and obsolete the
: custom
parameter.Obsolete the
: custom()
parameterTo start let's list all the possible scenarios supported by
Sylvia
:Empty
Interface implemented onEmpty
Contract.Empty
Interface implemented onCustomMsg
Contract.CustomMsg
Interface implemented onCustomMsg
Contract.IntoResponse
implementation aims to make "2" possible.To make the conversion mechanism automatic we could either make
Sylvia
deduce thatIntoResponse
has to be called or make it work in all three scenarios.Automatic detection is impossible as in minimal scenario all
contract
macro knows about the Interface implemented is the path to the Interface (hence the: custom()
parameter).#[sv::messages(path::to::interface)]
Implement
IntoResponse
for all scenariosCurrent implementation is as follows:
Important thing is that it's implemented only on the
Response<Empty>
. This is because we cannot implement conversion fromResponse<CustomMsg>
to some otherResponse<>
as it might loose the information in case theCosmosMsg::Custom
is sent. This is not an issue in case ofResponse<Empty>
asCosmosMsg::Custom(Empty)
doesn't carry any information and in fact shouldn't be constructed.Specialization
One approach to remove the need for
: custom
parameter would be to use theIntoResponse
always.In such case we would have to provide missing implementation for the "3" scenario. It's not possible unfortunately because of overlapping implementations.
Both of these implementations cover the
IntoResponse<Empty> for Response<Empty>
.This might be possible in the future with specialization feature implemented in Rust rust-lang/rust#31844, but it's unfortunately nowhere near being available.
Negative impls
This would be a workaround in providing specialization as we could make some marker trait that would be implemented on each type other than
Empty
, and then providing an old implementation forResponse<Empty>
and identity conversion in case of everyResponse<T> where T: Marker
.This is unfortunately also not yet available, but we can track it and consider in the future rust-lang/rust#68318.
Remove blanket implementation
Thanks to the
sv::custom
attribute we have access to potentialCustomMsg
used by the Contract. We can then generate a localIntoResponse
trait (has to be generated due to theorphan rule
) and implement it on all the scenarios, and in case of lack ofsv::custom
attribute either implement it only for the scenario "1" or just remove theIntoResponse
usage.No blanket implementation, no collisions.
This approach might be great in case of generics as while implementing the
Empty
Interface on Contract with generic type set in place ofCustomMsg
there should always be: custom
parameter added in case future user would apply theirCustomMsg
type in place of this generic type causing issue with lack of conversion not detected during the implementation of our Contract.This lack of concrete type however would require
IntoResponse
implementation to also be implemented on some genericT
which would turn into a blanket implementation leading us back to the original issue.Summary
At this moment I unfortunately don't see the solution to removal
: custom
attribute.The text was updated successfully, but these errors were encountered: