alloy-rs / core

High-performance, well-tested & documented core libraries for Ethereum, in Rust
https://alloy.rs
Apache License 2.0
764 stars 139 forks source link

[Suggestion] Improve API around (single) unnamed return values #580

Closed zerosnacks closed 1 month ago

zerosnacks commented 6 months ago

Component

contract

Describe the feature you would like

Follow up from conversation: https://github.com/alloy-rs/examples/pull/8#discussion_r1526788839

Consider the following:

 let Counter::numberReturn { _0 } = contract.number().call().await?;

Where Counter is implemented as follows:

contract Counter {
    uint256 public number;

    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    function increment() public {
        number++;
    }
}

It would be preferable to either:

Additional context

Any changes will be reflected in alloy/examples

mattsse commented 5 months ago

having an unwrapped return type would be more convenient, I think we can check this when analyzing the abi and check the outputs, if it's just a single type, use that

prestwich commented 5 months ago

we can, but it breaks encoding symmetry for any case where (T,) and T have different abi encodings, which would need to be accounted for

DaniPopes commented 1 month ago

We deemed the current API consistent and good enough. This change would require some specific workarounds and maybe hard to do in the current type system.

If you want return types to have a "nicer name" in functions, you can name them in the returns (...) tuple.

The example in the issue already has a named return value due to it being an elementary type getter: https://github.com/alloy-rs/core/blob/b4ca4fe483a8f5bee450a4ee627995b97249abbe/crates/sol-types/tests/macros/sol/mod.rs#L242-L255