Closed Kayanski closed 2 months ago
I don't think we should add
impl Into
for every type of argument.I suggest we add a match statement that only converts the arguments to
impl Into<>
for the types:* Uint (all sizes) * String
But not for
* Addr * Custom structures * booleans
This helps us keep the generated fns readable (as you can only see the generated code in your IDE).
Yes good idea ! We just need to keep in mind that because of how proc-macros work, we will not be able to accept such bounds on type aliases like :
pub type ChainId = String;
Attention: Patch coverage is 98.75000%
with 1 line
in your changes missing coverage. Please review.
Project coverage is 56.0%. Comparing base (
0a2f299
) to head (d1b2e96
). Report is 1 commits behind head on main.:exclamation: Current head d1b2e96 differs from pull request most recent head d43b34e
Please upload reports for the commit d43b34e to get more accurate results.
I don't think we should add
impl Into
for every type of argument. I suggest we add a match statement that only converts the arguments toimpl Into<>
for the types:* Uint (all sizes) * String
But not for
* Addr * Custom structures * booleans
This helps us keep the generated fns readable (as you can only see the generated code in your IDE).
Yes good idea ! We just need to keep in mind that because of how proc-macros work, we will not be able to accept such bounds on type aliases like :
pub type ChainId = String;
Is it possible to check it with typeid? https://doc.rust-lang.org/std/any/struct.TypeId.html
Is it possible to check it with typeid? https://doc.rust-lang.org/std/any/struct.TypeId.html
Undortunately not :/ See : https://users.rust-lang.org/t/get-type-information-in-proc-macro/48909
I don't think we should add
impl Into
for every type of argument. I suggest we add a match statement that only converts the arguments toimpl Into<>
for the types:* Uint (all sizes) * String
But not for
* Addr * Custom structures * booleans
This helps us keep the generated fns readable (as you can only see the generated code in your IDE).
Yes good idea ! We just need to keep in mind that because of how proc-macros work, we will not be able to accept such bounds on type aliases like :
pub type ChainId = String;
Think that's fine. We could add a field attribute (like payable
) that enables the Into manually as well.
Maybe we should start prefixing our macro attributes as well, like serde?
#[cw_orch(payable)]
#[cw_orch(into)]
Maybe we should start prefixing our macro attributes as well, like serde?
#[cw_orch(payable)] #[cw_orch(into)]
Pretty sure we should if we use such common phrases as into
haha
Maybe we should start prefixing our macro attributes as well, like serde?
#[cw_orch(payable)] #[cw_orch(into)]
Pretty sure we should if we use such common phrases as
into
haha
Yes there is a PR with that here already : https://github.com/AbstractSDK/cw-orchestrator/pull/408
This Simplify the cw-orch contract function derives.
The functions do not take their argument types directly but an argument of the form
Into<type>
This allows for simpler interactionsDepends on https://github.com/AbstractSDK/cw-orchestrator/pull/398
Downside
The types have to be known when specifying the argument. This is specifically bad when using
collect
. They should be changed tocollect::Vec<_>()
for instanceBreaking changes
Here are the cases that WILL break when releasing this PR. Cw-orch-core is not breaking
cw-orch-fns-derive breaks
Depends on https://github.com/AbstractSDK/cw-orchestrator/pull/398