what's the difference between call and just using function?

Question

Let's say I have a contract called contractA.

It has the function:

function bla(address test) {
    // way 1. test.call(abi.encodeWithSignature("first4bytes", arg1, arg2))
    // way 2. testAddrInterface(test).functName()
}

As you can see, in the way 2 example, I just use the interface so that I can call functName on it directly instead of using way 1.

I've seen lots of places that people use way 1. Why ? what's wrong with Way 2? if you tell me way 2 contains more code and is more gas costly, I will ask: are the interfaces still included in the final code and is this the only reason why Way 1 is better ?

Answer 1

The more important difference is that if funcName reverts then for case 2 bla will also revert.

For case 2 calls returns a boolean indicating if the call has failed, and have the posibility to ignore the failure.

Using raw call is low level and discouraged because it is easy to make mistakes. Since solc 0.6 you can use try/catch

    try myContract.funcName(param1, param2, ..) returns (uint retValue) {
        /* Do something with retValue */
    } catch Error(string memory err) {
        /* Do something with the error message and revert */
    }

Another place where case 1 is the only option is when making arbitrary calls since at compile time you don't know the function name nor the parameters, for example proxy contracts, multisig wallets, etc.

Answer 2

Effectively, there is no difference.

Using an interface provides compile time safety checks on arguments used. And simplifies the usage of return values the same way.

This is a quick, simple example, but basically these code lines are equivalent.

<Type> returnTuple = address.call( <payload as byyes> );

<Type> returnTuple = address.call( abi.encodeWithSelector( <Function Selector>, <Arguments . . .>);

<Type> returnTuple = address.call( abi.encodeWithSignature( <Function Selector string>, <Arguments . . .>);

<Type> returnTuple = address.f( <arguments> );

All would revert if the return tuple doesn't fit. When using call, you would normally accept the raw bytes. And then work with it from there. Such as returning, forwarding, or parseing.