ERC721: transferFrom with ApproveForAll emits event Approval

When users sets approve for all his tokens, and then some operators call transferFrom for some specific token, than Approval event is emitted. According to ERC-721 standard Approval event should not be emitted, because approve state was not changed for specific token.

    /// @dev This emits when the approved address for an NFT is ***changed*** or
    ///  reaffirmed. The zero address indicates there is no approved address.
    ///  When a Transfer event emits, this also indicates that the approved
    ///  address for that NFT (if any) is reset to none.
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);

I offer to change ERC721.sol function

    function _approve(address to, uint256 tokenId) private {
        _tokenApprovals[tokenId] = to;
        emit Approval(ERC721.ownerOf(tokenId), to, tokenId); // internal owner
    }

to

    function _approve(address to, uint256 tokenId) private {
        if (_tokenApprovals[tokenId] != to) {
            _tokenApprovals[tokenId] = to;
            emit Approval(ERC721.ownerOf(tokenId), to, tokenId); // internal owner
        }
    }

This will save gas on emitting and storing approve state.

[Amxx]

Coming back to @kindex

First of all, thank you for your issue. It really got us thinking and re-reading the ERC multiple time. We come to agree that the ERC is not clear, and that your comment is really pushing our interpretation of it.

Our analysis is:

• If someone calls approve(...) external multiple times, we should be emitting the event multiple times
• If _transfer is called, regardless of how it was called (safe/unsafe/by operator), we should reset the approval to 0. It is not clear if an Approval event should be emitted on top of the Transfer event (this is really unclear)

Your proposal would improve gas usage, but it would also break the first bullet point. It might be possible to improve event emission without breaking this, but it would require a non-trivial change of the codebase, for example changing the parameters of the internal _approve. This would be a breaking change for people building on top of this contract.

While we do care about gas costs, the complexity and the backward compatibility of the codebase are also very important, and we feel like it might not make sense to change things right now.

[fulldecent]

I agree that “this” in the following statement is unclear.

When a Transfer event emits, this also indicates that the approved address for that NFT (if any) is reset to none.

Sorry, my bad.