Change the new operator to use CREATE2

[chriseth]

This might require keeping a nonce or other measure to make the creation bytecode unique if new is used multpile times on the same contract.

See https://eips.ethereum.org/EIPS/eip-1014

[VoR0220]

Can you elaborate on this?

[axic]

Would that counter be shared across the contract for all creates, specific to the create in a certain code location or specific to creating a specific contract?

[AlexeyAkhunov]

I have written up this: https://ethereum-magicians.org/t/solidity-compiler-magicians-wanted-to-make-create2-usage-easier/2137

Yesterday I made this ERC20 contract (which is supposed to work under State rent when holders pay for storing their tokens): work: https://github.com/ledgerwatch/eth_state/blob/master/erc20/TokenContract.sol

As you can see in the code, Solidity provides create2 assembly function, but working with it is cumbersome. It would be much easier if there were 2 new features in Solidity:

1. new2 operator. Similar to new, but also accept salt parameter, and uses CREARE opcode. So in my Factory I would have written Holder holder = new2(Holder, _owner) without having to put the byte code of the Holder contract inside the function
2. Function create2_address, which allows computing address of CREATE2 contract. I would have used it twice, first in Token.getHolderContract function: address payable holder_address = create2_address(factory, a, Holder), and second in Holder.setOwner function: require(create2_address(factor, _owner, Holder) == address(this))

It would be great to have (at least in a branch) a version of Solidity (derived from the current) supporting these two things. That would make further development of contracts like that much easier.

[chriseth]

The new2 function you suggest could be rather tricky to implement. What might be easier and could be almost as helpful to you would be something like Holder.creationCode and Holder.runtimeCode - read-only properties of type bytes memory. What do you think?

[AlexeyAkhunov]

What might be easier and could be almost as helpful to you would be something like Holder.creationCode and Holder.runtimeCode - read-only properties of type bytes memory. What do you think?

Yes, that would definitely be helpful. And also the code hash, of course, because it can be computed at compile time

[chriseth]

The optimizer might take care of improving the hash computation, let's see.

[chriseth]

Created an issue #5647

[jochem-brouwer]

@chriseth Your bytes memory Holder.runtimeCode sounds dangerous. It is possible to create contracts which dump different runtime code than what you might expect. This involves using the return opcode in the constructor via assembly by hence pushing different bytes to the deployed code than what solidity expects it will deploy.

[chriseth]

Let's not discuss in two different issues -> #5647

[MicahZoltu]

Separate from the .creationCode and .runtimeCode, I would still like to see a new2 operator (that takes a salt). Dropping down to assembly should only happen when the higher level language doesn't support what you need to do, and if people are frequently dropping to assembly (as is happening with create2) that suggests the language is missing a feature that is in high demand.

Sometimes people drop into assembly to do things they shouldn't be doing, and I don't think we should be adding Solidity language features for such operations. However, using create2 is a good thing and should (IMO) be encouraged, but that requires a Solidity level language construct for it.

[haydenadams]

Whats the status of this? Would be nice to have a non-assembly CREATE2

[chriseth]

Any there any suggestions for the syntax? I really dislike the 2 in the opcode, by the way. What about

salted_new(salt) C(a, b, c)

or just

new(salt) C(a, b, c)?

We might even go so far to use

new(salt, value) C(a, b,c)

to replace (new(salt) C).value(value)(a, b,c)

[chriseth]

Suggestion by @leonardoalt : new.salt(s) C(a, b, c)

[chriseth]

Another suggestion by @leonardoalt: Also change to new.value(1 ether) C(a, b, c)

[leonardoalt]

And then you can combine them:
new.value(1000 ether).salt(42) C(a, b, c);

[chriseth]

I like new.salt(s) - we could introduce that with a non-breaking release already - although the parser looks a bit involved, so it might break the AST.

[chriseth]

We might change it so that .value and .salt are special expressions directly in the AST, though, instead of generic members of expressions.

[leonardoalt]

Suggestion from @axic:
new{salt=...,value=1} C(..)
new<salt=...,value=1> C(..)
If something like the above is accepted, the idea is to remove .value and .gas for all functions.

[chriseth]

I also like new{salt=..., value=...} C(...), but it's probably harder to parse <expression>{value=..., gas=...}().

[axic]

Maybe we actually need to look at this in conjunction with #2296 and that we could consider removing the new keyword entirely.

[leonardoalt]

Folks seem to converge to {...}, but I prefer [[...]] :p

[ekpyron]

Folks seem to converge to {...}, but I prefer [[...]] :p

Haha, I actually still like [[...]] better as well, but dropped it following the general tendency :-).

[axic]

[[..]] feels more like an annotation on a function declaration as opposed to an expression.

[3esmit]

I am writing account contracts and there is a specific use case where I am having to override a function because I am unsure about gas operator.
The override takes place to set if gas is manual or not.
There is a magic value (such as 0 or MAX_INT)? In case of {gas = 0}, what happens? and in case {gas = MAX_INT} (MAX_INT can be any value greater then the block gas limit)? To set the gas to "auto" I have to use {gas = gasleft()} ?

[chriseth]

Decsion: We use salt= as a determinator to use create / create2.

[chriseth]

Decision: We use {salt=...} and also go with {value=...,gas=...} for all external function calls.

[axic]

But is it new{} C or new C{} ?

[chriseth]

new C{}()

[chriseth]

Implemented in #8177