Add _initializableStorageSlot

[ernestognw]

Fixes #4782

Adding _initializableStorageSlot seems like a good abstraction for developers who want to override the initializable storage slot. This makes sense in the context of Account Abstraction since some wallets might reuse the slot. For these case it may be better that each implementation has its own customized slot.

PR Checklist

• Tests
• Documentation
• Changeset entry (run npx changeset add)

[changeset-bot]

🦋 Changeset detected

Latest commit: 8b4e292

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openzeppelin-solidity	Minor

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

[ernestognw]

Alternatively, we can make _getInitializableStorage internal. Thoughts?

[Amxx]

I'm concerned by line 63

     * when using with upgradeable contracts.
     *
     * @custom:storage-location erc7201:openzeppelin.storage.Initializable // <<== HERE !
     */
    struct InitializableStorage {

This comment will be wrong if the value is overriden. How will the plugin handle that ?

[Amxx]

function _getInitializableStorage() internal virtual pure returns (InitializableStorage storage $) {

Would be a smaller change, that we could easily generalize to all the upgradeable contracts. The downside is that overriding it would likely require the user writting assembly.

[arr00]

function _getInitializableStorage() internal virtual pure returns (InitializableStorage storage $) {

Would be a smaller change, that we could easily generalize to all the upgradeable contracts. The downside is that overriding it would likely require the user writting assembly.

I imagine that most teams requiring this functionality won't have an issue writing minimal yul. Don't think it's worth the extra function call just to bypass that.

lets discuss more

[Amxx]

function _getInitializableStorage() internal virtual pure returns (InitializableStorage storage $) {

Would be a smaller change, that we could easily generalize to all the upgradeable contracts. The downside is that overriding it would likely require the user writting assembly.

I'm just realizing that this would not really be "good" to generalize, because it gives the developper direct/easy access to the storage. Its basically like making the storage variables internal instead of private. I don't think its a good idea.

Right now I'd favor the current code.

@arr00 @ernestognw wdyt ? should we finally merge this ?

[ernestognw]

Would be a smaller change, that we could easily generalize to all the upgradeable contracts. The downside is that overriding it would likely require the user writting assembly.

I agree with this concern. However, I don't see a way around It given you can't override the NatSpec struct annotation.
Theoretically, if a user overrides the storage pointer using ERC-7201 (which the function already recommends), then collision should not be a risk.

I'm merging this PR, but I think we can discuss exploring an special annotation like @custom:storage-location-renamed-from erc7201:openzeppelin.storage.Initializable <...>

EDIT: I can't merge. Need approval again