address.code and address.codesize

[axic]

Add a member called "code" to the address type that returns a variably-sized byte array which contains the code at that address.
Translate "address.code.length" directly to CODESIZE.

(From https://www.pivotaltracker.com/story/show/89623638)

[axic]

With Constantinople's extcodehash feature this should also support address.hash or address.codehash.

[axic]

I think these features would be nice, especially considering that a lot of contracts now use assembly to access them, which puts an extra burden on the SMTChecker.

cc @leonardoalt

Probably should be considered in conjunction with #4910

[chriseth]

.codeHash, .code, .codeSize? Or .codeLength?

[axic]

I think codesize is fine as it is close to the opcode. A user can also do code.length at the cost of memory expansion, unless we want to make a weird shortcut where code.length translates to extcodesize.

Also question: should the compiler generate codesize/codecopy (and not extcodesize/extcodecopy) in case of address(this).codesize and address(this).code?

[chriseth]

Sure, same mechanism as with selfbalance.

[chriseth]

Let's implement .code as memory array with a shortcut for .code.length (and for codecopy / extcodecopy)

[axic]

We agreed to .code (and .code.length), but there seems to be no clarity on hash. Is it .hash or .codeHash or .codehash? Or adding yet another hack of translating keccak256(...code) in the codegen? I would rather not.

[axic]

Or adding yet another hack of translating keccak256(...code) in the codegen? I would rather not.

Actually a good point against this is the push for code merkleization (i.e. EIP-2926) which would change the way the codehash is calculated.