Solidity: Address Payable Conversion

[decanus]

Currently the way to convert an address to a payable one. Is by using address(uint160(addr)).

This is a ugly and not understandable on first sight. It would be ideal if there was a nicer way to do this conversion.

[leonardoalt]

We are currently thinking about a way of doing that without looking even uglier or more confusing.

One idea was
address payable a = payable(addr);

[decanus]

@leonardoalt I think the above solution is definitely better than what we currently have.

[scucchiero]

I run into the same issue.
Great to see we both came up with the same solution.

[leonardoalt]

If we decide to implement this, we need to define the rules for payable(x) and address(x).
Currently, address(x) returns address payable if x is payable, otherwise address.
This would overlap with the new payable(x) which always returns address payable.

Also, there are tricky situations, for example with this. If this does not have a fallback function, should payable(this) issue a compilation error? Should it give an address payable anyway?

Regarding the overlap between address(x) and payable(x), do we keep this overlap, or do we make address(x) always return only address?

This needs to be well specified. After talking to @ekpyron yesterday I'm again not sure this is a good idea at all.

[ekpyron]

A cast of the form payable(x) seems weird to me, whenever x is not an address - but if we move away from having the result type of address(x) depend on x, we'd probably need payable(x) for integers and contracts...
Also to me it seems having payable(this) silently return an address payable kind of defeats the entire purpose of splitting address - so I'd at least require payable(address(this)) in that case...
But yeah, I'm not sure about the entire thing myself anymore either.

If we still want to do this and if we're fine with payable(x) for uint160 x;, then I'd specify as:

• address(x) always returns address, i.e. it's just the explicit conversion to address
• payable(x) always returns address payable, i.e. it's just the explicit conversion to address payable
• Contracts with payable fallback are explicitly convertible to both address and address payable
• Contracts without payable fallback are explicitly convertible to address only
• address is explicitly convertible to address payable
• address payable is implicitly convertible to address as before
• uint160 is explicitly convertible to both address and address payable (and vice versa)

An alternative would be to continue to let address(x)'s return type depend on x and only allow payable(x) for address x; - but that seems quite weird to me.

Given payable(x) for uint160 x; I'm not sure anymore whether address payable(x) might - although weird as well - still be the better alternative to payable(x) in general.

So yeah, that'd be my current stand on this, but more opinions would be really good...

[leonardoalt]

I think requiring the argument of payable to be an address is not too bad.

[chriseth]

I would prefer to only allow payable(x) if x is an address. address(x) returns an address or an address payable depending on x.

[ekpyron]

Yeah ok, if you both agree on that, I'm fine with it.

It's just quite different from other types and their conversions that way (and if we have explicit casts for address and address payable, then there's less pressing need for all these exceptions than before), but maybe that's just how it is.

[leonardoalt]

Implemented in https://github.com/ethereum/solidity/pull/7349