Skip to content

AbiEncoderv2 default getter return types #6337

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
rainbreak opened this issue Mar 20, 2019 · 6 comments
Open

AbiEncoderv2 default getter return types #6337

rainbreak opened this issue Mar 20, 2019 · 6 comments
Labels
breaking change ⚠️ language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap.
Milestone

Comments

@rainbreak
Copy link
Contributor

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
Copy link
Contributor

Skyge commented Mar 21, 2019

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
Copy link
Contributor

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
Copy link

Any plans to support this?

@cameel
Copy link
Member

cameel commented May 27, 2022

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;
}

@cameel cameel added the language design :rage4: Any changes to the language, e.g. new features label May 27, 2022
@github-actions
Copy link

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 github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Feb 22, 2023
@github-actions
Copy link

github-actions bot commented Mar 1, 2023

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.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label Mar 1, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 1, 2023
@cameel cameel added should have We like the idea but it’s not important enough to be a part of the roadmap. and removed closed due inactivity The issue/PR was automatically closed due to inactivity. stale The issue/PR was marked as stale because it has been open for too long. labels Oct 18, 2024
@cameel cameel reopened this Oct 18, 2024
@cameel cameel added breaking change ⚠️ low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. labels Oct 18, 2024
@cameel cameel added this to the 0.9.0 milestone Oct 18, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
breaking change ⚠️ language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap.
Projects
None yet
Development

No branches or pull requests

5 participants