It looks like @thomaseizinger hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

[clabot:check]

It looks like @thomaseizinger signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

The two methods from_sender_salt_and_code and from_sender_and_code both return a tuple with the computed hash. I don't know how these methods are actually being used, so I don't know if we actually need that return value. It seems a bit odd to me because it looks like the hash is an implementation detail of how to compute the address and should be hidden inside the function.

Yes, the code hash is used, although it looks weird.

Not all variants of scheme used all the parameters of the previous contract_address function, yet they still needed to be passed.
I took a shot at redesigning the interface of this crate to allow for the most convenient usage.

Thanks, the usage is indeed seems more convenient now. But we have code that passes the enum around, so we need to keep it.

Yes, the code hash is used, although it looks weird.

The code that is passed is hashed as the first step in the function. If the hash is needed outside of that function as-well, I'd propose to change the signature of these functions to accept the hash directly instead of the code, then we can remove the awkward tuple return value and the calling code gets to still have the code_hash.

Would that change work for you?

Thanks, the usage is indeed seems more convenient now. But we have code that passes the enum around, so we need to keep it.

What are your thoughts on this PR then? Should I add the scheme back and provide a 4th method?

In the spirit of providing a useful, general-purpose crate for computing contract addresses for Ethereum, I feel like the need to pass around a creation-scheme is fairly application specific and does not really need to be in this crate? 😬

The code that is passed is hashed as the first step in the function. If the hash is needed outside of that function as-well, I'd propose to change the signature of these functions to accept the hash directly instead of the code, then we can remove the awkward tuple return value and the calling code gets to still have the code_hash.
Would that change work for you?

Yes, sounds reasonable.

What are your thoughts on this PR then? Should I add the scheme back and provide a 4th method?
In the spirit of providing a useful, general-purpose crate for computing contract addresses for Ethereum, I feel like the need to pass around a creation-scheme is fairly application specific and does not really need to be in this crate?

I agree :) Let's remove the enum.

@ordian As discussed, I removed the hashing and the tuple return value :)

Let me know, if this PR needs anything else from my side!

Could you update the readme (the doc tests unfortunately don't run on CI) and bump version to 0.2 as well?

• Bumped version
• Updated README
• Added step to CI to run doc-tests on nightly (can drop that commit if you don't like it!)

Published 0.2.0