-
Notifications
You must be signed in to change notification settings - Fork 185
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
refactor(store): order load function arguments [N-02] #2033
Conversation
🦋 Changeset detectedLatest commit: d2ef9b6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think aligning the order is a good call and i think the storagePointer
, offset
, length
, memoryPointer
order makes sense, so it would be:
store(uint256 storagePointer, uint256 offset, bytes memory data)
store(uint256 storagePointer, uint256 offset, uint256 length, uint256 memoryPointer)
load(uint256 storagePointer, uint256 offset, uint256 length)
load(uint256 storagePointer, uint256 offset, uint256 length, uint256 memoryPointer)
unfortunately this also means we need to adjust it in all consuming libraries and need to be very careful because the types are all uint256
so the compiler won't help us
@alvrs this was easier because most consumers call the functions with named arguments. Do we want to align the order there for consistency? ie. bytes memory data = Storage.load({ storagePointer: storagePointer, length: 34, offset: 31 }); VS bytes memory data = Storage.load({ storagePointer: storagePointer, offset: 31, length: 34 }); |
no need to change the order in consumers with named arguments imo! |
if we have fewer than a ~dozen call sites, would vote to align order for consistency, even though it's not technically necessary |
Agreeing with Frolic I have aligned the order on the named arguments also |
"gasUsed": 245 | ||
"gasUsed": 2300 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we know where this is coming from? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given that this increase isn't showing up in ~every other gas report, I am guessing something unrelated is going on
Arguments are now in the same order as the
store
function.