Redefine struct getters to return their struct type, not a tuple of individual fields

[rainbreak]

With the AbiEncoderv2, is the intent to have structs returned from auto-generated getters for public storage?

For example,

struct Data {
    uint256 x;
    bytes32 y;
}

mapping (bytes32 => Data) public data;

This exposes the getter function data(bytes32) public view returns (uint256,bytes32)

Is it possible that it could instead expose function data(bytes32) public view returns (Data)?

[Skyge]

I think you can not only get a struct type from a function with the ABIEncoderV2, but pass a struct type into a function.

[chriseth]

The automatic getters were designed before structs in the ABI were even considered. Especially for arrays, getters as they currently are make sense in certain cases, so I'm a bit reluctant in changing the behaviour altogether. We could change the detail about returning structs once ABIEncoderV2 is the default, though. I would not change it earlier because activating ABIEncoderV2 currently does not silently change the external behaviour of contracts.

[pedrobergamini]

Any plans to support this?

[cameel]

No plans so far but I agree that we should start finally thinking about changing it. Maybe 0.9.0 would be a good moment to take care of it.

The way this works currently is really unintuitive, especially combined with overriding. It was brought up in #11826 some time ago. For example to be able to override a getter defined in an interface with an actual getter you need an extra wrapper:

interface I {
    struct S { uint a; }
    function s() external returns (S memory);
}

contract C is I {
    struct WrappedS { S s; }
    WrappedS public override s;
}

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.