Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
REVERT, STATICCALL, RETURNDATASIZE and RETURNDATACOPY are all approved and pending the next Ethereum hardfork as specified here
However, the Solidity changelogs shows all 4 of these opcodes entering the compilers services before the hardfork has happened?
Is this actually the case? How is this possible? Do all ethereum programs such as Geth and Parity introduce the opcodes before the hardfork also?
Yes, they are indeed available now in Solidity as opcodes in assembly, along with CREATE2, and you are free to use them. However, for the time-being they will just fail with "invalid opcode" if any pre-Metropolis EVM tries to execute them - i.e. any node on the current main net.
I think the intent here is to allow for pre-release testing of Metropolis using the mainstream Solidity compiler. The assumption is that anyone using assembly code is knowledgeable enough to know what to expect.
REVERT is an interesting case. Even though the EVM doesn't yet implement it, the intent of the REVERT opcode is fairly similar to the "invalid opcode" exception. Sufficiently so that the compiler has implemented (and encourages us to use) the revert() function already, instead of the throw keyword. This actually inserts a REVERT opcode into code intended for deployment today (pre-Metropolis), which is technically invalid but does the job. After Metropolis the behaviour of this already deployed code will change to perform the softer revert exit rather than a hard throw.
