Upgrade to cosmwasm 0.16 #378
Conversation
| app.wrap() | ||
| .query_wasm_smart::<Reply, _, _>(&reflect_addr, &query) | ||
| .unwrap_err(); | ||
| let res: StdResult<Reply> = app.wrap().query_wasm_smart(&reflect_addr, &query); |
There was a problem hiding this comment.
@uint I was forced to change this with the impl changes. I first changed <Reply, _, _> to simply <Reply>, but I got:
error[E0632]: cannot provide explicit generic arguments when `impl Trait` is used in argument position
--> packages/multi-test/src/app.rs:676:33
|
676 | .query_wasm_smart::<Reply>(&reflect_addr, &query)
| ^^^^^ explicit generic argument not allowed
This is how I got it to compile. Maybe you have another idea?
(This is only a bit of a pain with unwrap_err(), so not a big deal, mainly curious)
There was a problem hiding this comment.
@ethanfrey Oh, huh. I had no idea that's a limitation. I think your change is perfectly fine, but I also think we should just switch back all the fns in the std that have type parameters alongside impl blocks. We (arguably) lose a little cosmetically, but if users get to use turbofish syntax again, that's worth it.
There was a problem hiding this comment.
Then again, something like ::<Reply, _, _> is not pretty. No one sane will ever want to type out the last two types. Hm.
There was a problem hiding this comment.
No need to change here.
Since this is only needed for unwrap_err() (normally we just do let res: Reply = ... ?, I would not change the API here. Just something to be brought up if there are cases where we have impl and generics mixed and the generic cannot be easily inferred by the input type or the return value. I believe this is the case some places where we take closures as arguments.
There was a problem hiding this comment.
But let's not change the std lib now. I just wanted to flag it for reflection. One place in ~20 contract with a simple work-around doesn't make it a bad API decision.
Closes #377