Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

ERC1155: reorder of KeyTypes in _balances #5023

Open
pcaversaccio opened this issue Apr 22, 2024 · 3 comments
Open

ERC1155: reorder of KeyTypes in _balances #5023

pcaversaccio opened this issue Apr 22, 2024 · 3 comments
Labels
breaking change Changes that break backwards compatibility of the public API.

Comments

@pcaversaccio
Copy link
Contributor

pcaversaccio commented Apr 22, 2024

It might be nit, but you define _balances in your ERC1155 implementation accordingly:

mapping(uint256 id => mapping(address account => uint256)) private _balances;

but the balanceOf function uses the (switched) EIP-1155-compliant way as function arguments:

function balanceOf(address account, uint256 id) public view virtual returns (uint256) {
    return _balances[id][account];
}

I would propose to change _balances to:

mapping(address account => mapping(uint256 id => uint256)) private _balances;

in order to avoid confusion and to keep consistency with the balanceOf function. My guess, why it has been implemented like this in OZ, is the official EIP implementation here.

@ernestognw
Copy link
Member

Hey @pcaversaccio,

Took a quick look at the code because I agree it feels weird. So far I agree with the rationale but changing the order of the mapping is a breaking change for upgradeable contracts. I don't think we can fix that until 6.0 and it doesn't harm.

@pcaversaccio
Copy link
Contributor Author

Hey @pcaversaccio,

Took a quick look at the code because I agree it feels weird. So far I agree with the rationale but changing the order of the mapping is a breaking change for upgradeable contracts. I don't think we can fix that until 6.0 and it doesn't harm.

Yeah it doesn't harm and you guys can patch it whenever the timing is ready. I just think it's kinda confusing and should be patched one day at least.

@ernestognw ernestognw added the breaking change Changes that break backwards compatibility of the public API. label Apr 22, 2024
@ernestognw
Copy link
Member

Sounds good to me, I'm labeling this as a breaking change so we take a look back when we work on a new version.

Thanks for raising it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes that break backwards compatibility of the public API.
Projects
None yet
Development

No branches or pull requests

2 participants