Add ContractCall::call_owned(self)

[TmLev]

Motivation

I was trying to call multiple contracts concurrently by aggregating calls into a vec, so that I can join_all(calls).await them later.

Since ContractCall::call(&self) takes an immutable reference, compiler prevents future from being created because future references ContractCall, which may not live long enough.

I’ve tried Box-ing ContractCall, but it didn’t quite work.

Solution

Add another method that takes ownership: call_owned(self).
That completely solved my problem.

PR Checklist

• Added Tests
• Added Documentation
• Updated the changelog

[TmLev]

Can update the changelog, if needed.

[mattsse]

I also stumbled across this a couple of times.

this is useful if you need to move the future around.

An alternative could be to implement this if the type is Clone but I think contract.clone().call_owned` is better.

needs cargo + nightly fmt

[TmLev]

Will do in a couple of minutes

[TmLev]

Done

[TmLev]

@gakonst maybe merge? :)

[prestwich]

can't you just wrap in an async move {} block that takes ownership?

[TmLev]

Yeah, that should work. You think that call_owned(self) is redundant?

[prestwich]

tbh, I think that making call() consume self might be ideal?

[TmLev]

Not necessarily?.. In case you want to estimate gas and do a transaction, after which transaction may fail and you want to retry?..

[prestwich]

well, the user intent for .call() is to read the chain. there's no usage I can think of in which the ContractCall is not dropped after the eth_call is executed. So fn call(self) is probably more in line with user expectation than fn call(&self)

[TmLev]

In case it fails because of the provider and user wants to retry.

[prestwich]

ContractCall is Clone so that user could clone it before calling call() or send() 🤔

[prestwich]

I think much better dev ergonomics for joins is probably worth slightly worse dev ergo for retries? 🤔

[TmLev]

Joins can be solved with async move { ... } blocks, as you said. .clone()-ing the call for retries is not ideal.

[prestwich]

slept on it. this would be a good place to implement IntoFuture, and keep call() and send() the same as they are now. my_call.into_future() is a lot more sensible to read than async move { my_call.call() }

[gakonst]

Same page as Prestwich, let's replace with IntoFuture.

[TmLev]

ContractCall has three async methods:

• estimate_gas
• call
• send

I'm not sure how IntoFuture can handle not just one, but all three of the use-cases.

Or are you suggesting to create new type (say, ContractCallFuture)? But what this type is supposed to do?

[gakonst]

I'd default to call() and ignore the other 2