Add a "safe way to send ether" i.e. address.transfer

[chriseth]

address.send does not send along any gas and does not propagate exceptions. This is good for situation where we do not know the target, but those are limited in use as was discovered in the meantime. People resort to workarounds like recipient.call.value(x)(). Exactly this workaround should receive a name and it should propagate exceptions.

Suggestions for the name: transfer (sounds safer because transfer usually asks you to watch the whole process)

[ethers]

LGTM. When this is implemented, could a warning message when address.send is used, be displayed and to suggest that the user probably wants to use address.transfer ?

[PeterBorah]

As we've seen in the past couple weeks, recipient.call.value(x)() is very dangerous. I would therefore suggest that this method, if implemented, limit gas like send() does, with the only difference being the error propagation. Otherwise this will be exacerbating the reentry problem.

[axic]

Wouldn't the main suggested use for transfer be sending value to addresses or accounts? And in the case of accounts, strictly to the fallback function?

In that case it should by default include gas enough for that only and offer the .gas(n) modifier.

ie. address.transfer(1 ether) and address.transfer.gas(120000)(1 ether)

[axic]

I think it may make sense rejecting 0 value transfers as those seem like circumventing the real purpose of transfer.

[federicobond]

Is error bubbling the only difference between send and transfer? I am worried that people may confuse these two, since there is little semantic clue in those names to distinguish between them.

Also, if the plan is to eventually deprecate send (to avoid this confusion), what would be the recommended migration path? Contracts could easily lock themselves if they carelessly replace send with transfer, right?

[axic]

Two differences:

• throw on error
• supports the .gas() modifier to override the supplied gas

if the plan is to eventually deprecate send

See #1666. Both will be available, send should be deprecated, maybe removed in the future.

Contracts could easily lock themselves if they carelessly replace send with transfer, right?

If they just replace it and the target throws, then I guess they could have situation their code won't progress forward. Hence this has a new method name and we're not changing send.

[federicobond]

Thanks for the clarification!

[chriseth]

This is implemented in develop.