Data storage and representation in the EVM
address payable types both store a 160-bit Ethereum address. The concept of payable and non-payable addresses only exists in the Solidity type system at compile-time. The difference between payable and non-payable addresses is gone in the compiled contract code.
You can use
address payable, but not on
You can use a low-level
.call(..) on both
address payable, even if you attach value to it. This is not recommended.
address payable to
address payable can be implicitly or explicitly cast to
address payable addr1 = msg.sender;
address addr2 = addr1; // This is correct
address addr3 = address(addr1); // This is correct
address can only be explicitly cast to
address payable. Casting any integer type like
address produces an
address addr1 = msg.sender;
address payable addr2 = addr1; // This is incorrect
address payable addr3 = address(uint160(addr1)); // This is correct
Although a single
address payable can be cast to
address, arrays of one address type cannot be cast to arrays of another address type:
function testCast(address payable memory _addresses) returns (address memory)
return _addresses; // Type error!
Types in programming languages exist for two reasons:
To provide special type-specific semantics (e.g.
+ on numbers is addition, but
+ on strings might be concatenation)
To limit the amount of incorrect programs that are accepted by the compiler
The splitting of addresses into
address payable serves the latter purpose. It forces the smart contract programmer to think about whether an address should ever receive ether from the smart contract. If it should never receive Ether, the
address type can be used. Compilation will fail with a type error if the programmer makes a mistake and tries to transfer Ether to that address.
Built-in address constants
msg.sender is an
tx.origin is an
block.coinbase is an