Discussion: Either revert or return success, not both

[deluca-mike]

There is a bit of an anti-pattern going on in the space where success/ok return values aren't actually used, which can waste gas, and further pushes the need for "safe" helpers to handle this issue.

I believe we should pick one and stick with it: either revert on a failure, and return nothing, or don't revert and return the success status.

Pros for reverting (which are de facto Cons for returning success):

• EOA can call the functions and immediately see the if it failed or not, without needing to check beyond the status in the tx receipt, and wallets can detect failures pre-flight. Also, if an EOA is using a primitive wallet that has no pre-flight checks, the revert string should show up on popular explorers like etherscan.
• No need for callers to wrap the calls in requires, in their code, however, everyone is already wrapping their erc20 calls in "safe" helper functions...
• Not gas wasted on some static return true; and return type, which is meaningless.

Cons for reverting (which are de facto Pros for returning success):

• Revert strings are baked into the erc20 contract, wasting bytecode space and runtime gas (since they are often ignored and replaced with the ones thrown by the "safe" helpers, for internal calls. Further, more often than not, these revert strings would be in a different "domain" and style.
• No easy way to fork logic based on if a transfer/approval fails or not.

[JGcarv]

I agree with the case that we are using an anti-pattern, which is far from ideal.

However, this is something that comes from ERC20 itself and I don't think we should change. Composability is a big part of the ecosystem, so my take is that the token should do what most people expect it to do. I'm afraid that by making things right we might cause more problems than keeping the wrong like everybody else.