Update EIP-223: Remove standard function

[Pandapip1]

ERC-223 needs an errata:

1. In Add EIP-223: Token standard with event handling implementation #6485 (comment), I noted that the standard function was out-of-scope and insisted that it be removed
2. In Add EIP-223: Token standard with event handling implementation #6485 (comment), @Dexaran acknowledged that it was indeed out-of-scope and removed it
3. In Update EIP-223: Update eip-223.md #7466 / ff3ec32, the function was mistakenly re-introduced
4. The optional function remains out-of-scope and inadequately specified.

Removing this function is a backward compatible change, as applications cannot expect it to be present.

[eth-bot]

File EIPS/eip-223.md

Requires 1 more reviewers from @Dexaran
Requires 2 more reviewers from @axic, @gcolvin, @lightclient, @SamWilsn

[Dexaran]

I would support this changes but the removal of this function now would require the update of the reference implementation code as well since the function is also presented there.

I'm also working on a Token Standard Converter as according to EIP-7417 (btw that would help if you could merge the EIP-7417 PR, I'm waiting for it for 3 weeks without any response)

The standard() function is also part of the token converter (https://dexaran.github.io/token-converter/) now https://github.com/Dexaran/TokenStandardConverter/blob/main/TokenConverter.sol#L135 as it's the best way to identify if a token is supposed to work as a ERC-20 token or as a ERC-223 token. EIP-165 does not provide a deterministic answer since ERC-20 and ERC-223 token interfaces can match even though the logic of the transferring is different.

Even though the "standard recognition" can be reinstated as a separate informational EIP here is the question - is it worth the effort to remove it from a final EIP and reference code just to make it a separate EIP?

[Pandapip1]

I would support this changes but the removal of this function now would require the update of the reference implementation code as well since the function is also presented there.

Actually, it's perfectly fine for you to keep the standard function there! If you'd like it removed, however, I'd be happy to comply.

I'm also working on a Token Standard Converter as according to #7418 (btw that would help if you could merge the EIP-7417 PR, I'm waiting for it for 3 weeks without any response)

Sorry about the wait. I'll look into it!

The standard() function is also part of the token converter (https://dexaran.github.io/token-converter/) now https://github.com/Dexaran/TokenStandardConverter/blob/main/TokenConverter.sol#L135 as it's the best way to identify if a token is supposed to work as a ERC-20 token or as a ERC-223 token. ERC-165 does not provide a deterministic answer since ERC-20 and ERC-223 token interfaces can match even though the logic of the transferring is different.

The interface ID is the XOR of all the function selectors, so they should be different. https://eips.ethereum.org/EIPS/eip-5269 and https://eips.ethereum.org/EIPS/eip-1046 might also interest you, although the latter applies less directly to your token converter EIP.

Even though the "standard recognition" can be reinstated as a separate informational EIP here is the question - is it worth the effort to remove it from a final EIP and reference code just to make it a separate EIP?

Considering most if not all of the work would be done by editors, I'd say yes, this is worth it. Take a look at ERC-165 and/or ERC-5269 and let me know what you think! ERC-5269 is still in Review, so if you have any strong feelings, @xinbenlv will probably be able to collaborate with you to refine them!

[SamWilsn]

I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually.

As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process.

If there is relevant history here, please link to this PR from the new pull request.

On behalf of the EIP Editors, I apologize for this inconvenience.