Feature Updates

chriseth

I would like to use this thread to announce new Solidity language features as soon as they arrive in the develop branch of cpp-ethereum. The compiler should be stable and tested at all times, but we can not always prevent bugs from sneaking in. If you encounter anything strange, please do not hesitate and open an issue in github.

Just now, interaction between contracts was added. It is now possible to create contracts from within Solidity. For an example, please see the tutorial.

Bitcoinzie

The lack of semi-colons in the other languages was driving me nuts

chriseth

Not really a feature but a heads up:
The keyword "const" has been changed to "constant". Depending on the version of the compiler or the source you use, this might hit you as "Expected token LBRACE".

chriseth

The type limitations for integer literals were lifted. The type is now determined at the point where something else than integer literals is involved (similar to the way it is in go). For details, please see the tutorial on the wiki.

Jikmo

Hey chriseth. Great work you've been doing.

When will we be able to send ether along with a method call to another contract and along with contract creation?

chriseth

This is the next big feature, it should be ready by the end of next week.

Jikmo

Awesome. Thanks Chriseth.

Any idea what the syntax will be so I can write it into my contract right now?

Jikmo

Chriseth, I'm getting a very weird error from the compiler:

Error: Compiled contract not found.

Any idea what's wrong? My contract is reeaally long. 250 lines. That's the only thing I can think of.

Jikmo

Never mind. I figured out the error:

I had 2 contracts in my code, and I needed to have the full contract of one of them before the call to new.

chriseth

Solidity now supports contract inheritance in latest develop and in the browser-based compiler:
https://github.com/ethereum/cpp-ethereum/wiki/Solidity-Tutorial#contract-inheritance

chriseth

New feature: Function modifiers

chriseth

It is now possible to change the visibility ("public"/"private") of functions and storage variables, a contract can define a "fallback function" and we have events to make logs (the SPV helper mechanism) easier. Details in the tutorial. The reason why we also have "public" for storage variables will be clear soon ;-)

chriseth

New feature: Automatic state variable accessors.

chriseth

New feature: Ether units.

drcode

Hi criseth... All this is great, but I am baffled by the PT Events feature- It would be awesome if you expand on the tutorial description to make it more "ELI5"... Is this a feature that's currently usable in go-ethereum+ethereumjs?

chriseth

There is some more information in the ABI specification. In general, the workings of events should rather be documented in some "how to write a simple dapp in Solidity and JavaScript" tutorial.

chriseth

We have arrays!
Beware that arrays as function parameters only work in external functions for now.

StephanTual

@chriseth - Hurray!

Atomrigs

Greate !!
I hope we also can save arrays on the storage.

drcode

@chriseth, mind if I ask what the cost of a lookup is? Are any SHAs performed during a lookup into a one-dimensional array in storage?

chriseth

If the size is fixed, no SHA is involved. If the size is dynamic, a SHA is performed, but this SHA is the same for all indices so it might soon be optimized away for multiple lookups.
Note, however, that by the recent changes in gas costs, SHA is only slightly cheaper than loading from storage and modifying storage is more than 100 times more costly than the SHA, and using a new storage slot is almost 1000 times the cost of a SHA.

chriseth

I have been neglecting this thread for some time. In the meantime, we added a lot of features:

• storage is now tightly packed, so it acutally does make sense to use uint8 and such
  
• there is a decent optimizer that reads in blocks and completely re-generates them (make sure to activate it!)
  
• storage variables can be declared constant and do not take space in storage (only in code)
  
• accessor functions are generated for array types
  

I also updated the browser based compiler to the most recent version. The UI will likely also receive an overhaul in the next days.

robmyers

Hey awesome! Constants were on my must-have list.

terzim

@chriseth question: what's the correct type for text in the current version, bytes32 or string?

chriseth

The types bytes0 to bytes32 contain fixed-length byte strings (of up to 32 bytes) while "bytes" can be of arbitrary length and is also resizeable. So you probably want "bytes".

Smithgift

@terzim: Not a dev myself, but the current Ethereum protocol doesn't have any way to for contracts to call themselves. So yes, you'll probably have to have someone call the function every month.

chriseth

The solidity compiler now has a way to tell how much gas will be used by the various functions of the contract - regardless of the parameter values.

contract Contract {
  bytes data;
  function g(uint x, byte y) {
    if (x > 10)
      data[x] = y;
  }
}

$ solc /tmp/contract.sol --gas --optimize 1

======= Contract =======
Gas estimation:
construction:
   54 + 32800 = 32854
external:
   g(uint256,bytes1):	20708
internal:

Note that the gas used by g is different, depending on the value of x. Solidity does its best to try and find the maximal gas value (here, 20708). For the cases where this cannot be done or if Solidity is not clever enough (for example if the code contains loops), it prints [???].
For the "construction" part, the two summands are the gas used for executing the constructor(s) and the code storing fee, respectively. If another function is called internally, its gas cost is added to the actual function, but the costs of externally called functions are not added.

chriseth

Exceptions: If arrays are accessed out of bounds or externally-called functions fail (e.g. due to out of gas), the current execution is also stopped immediately in a failure state. This has the effect that all changes (to state or balance) are reverted.

As this would be quite problematic for send() or non-typesafe calls like call() or callcode(), these functions do not propagate the failure condition but rather return a boolean indicating whether the call succeeded (true) or not (false).

Eventually, Solidity will also receive a throw keyword to manually cause this failure condition and perhaps also try { } catch { }, although try/catch will have rather limited functionality.

chriseth

Finally, in-memory arrays are finished. You can now pass memory-arrays as arguments of functions and also return arrays from functions. Please take special care about the subtleties involved in memory and storage reference types (e.g. arrays).

Furthermore, the Tutorial has been partly re-worked.

Pranay

great work.

chriseth

Storage references now occupy only one stack slot instead of two. This might resolve some of the "Stack too deep" errors you are getting! I just checked: The "order statistic tree" compiles again :-)