Francisco Giordano

Oh I hadn't noticed that. It's a pretty interesting idea, but I don't think I'd feel comfortable recommending it. `transferFrom` is not the only thing the receiver may use `msg.sender`...

Thank you for the proposal @a-d-j-i. I think this is actually a very good idea for the upgradeable contracts, but we will need to carefully consider it for the next...

@byterose As I mentioned above: >we will need to carefully consider it for the next major release because it is a breaking change. There is currently no major release planned...

We don't really want to maintain a third variant of the repo, maintaining two is already significant workload, so if we go this route we would make it the default...

@a-d-j-i What kinds of backwards compatibility are you looking for?

@a-d-j-i In the fork by @GVTopCoder there is no way to update that. The way we're planning to adopt the diamond storage pattern in our next major is by defining...

Yes, we want to adopt diamond storage for the next major release, but we don't have an estimated release date. It will most likely happen whenever Solidity 0.9 is released,...

Sorry, as warned in [the readme](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable#readme) for the upgradeable contracts: >There will be storage incompatibilities across major versions of this package, which makes it unsafe to upgrade a deployed contract...

Yeah I think the best option is to use an array of EnumerableSet and just move on to the next one when you clear. ```solidity // SPDX-License-Identifier: MIT pragma solidity...

@hrik2001 Yes go ahead! I've added function signature to the issue description.