Is there any concern to not have done it yet (maybe this issue #207)?

Also are you comfortable to split the current ERC721 implementation between ERC721 and ERC721Metadata (in order to have ERC721Metadata defined as an extension separated from the core ERC721)?

@Bal7hazar i think the best is to wait for components to streamline this eventual separation.
although not a blocker, another feature that'd help here is supertraits (or similar) to extend a trait with another i.e. extend ERC721 by just defining the metadata-specific fields on top. I think there might be a way of emulating it now though.

@martriay thanks for sharing your thoughts, just to ensure I understand well, do you think it's risky for the community if OZ repo have a pre-component implementation right now and make another other one after the component feature is released (with the risk of changing the signature or storage making the upgrade not possible easily) ?

I understand that you could have other priority, my point is if I (or someone else) make a PR with a proposition right now, would you accept to merge it in the repo? (Assuming it passes the merging process ofc).

@Bal7hazar sorry for the long silence. are you still willing to work on this?

Hey @martriay actually there is already a component version made by Seraph-Labs:

https://github.com/Seraph-Labs/Cairo-Contracts/blob/main/src/tokens/erc721/extensions/enumerable.cairo

Great! That'd be a useful reference. We're still going to add this to our library, I expect us to work tackle it sometime during Q1 2024. Anyone interested in tackling it before will be welcomed :)