Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc: Order of Evaluation of Expressions #4579

Closed
hiqua opened this issue Jul 25, 2018 · 4 comments
Closed

Doc: Order of Evaluation of Expressions #4579

hiqua opened this issue Jul 25, 2018 · 4 comments

Comments

@hiqua
Copy link

hiqua commented Jul 25, 2018

Given http://solidity.readthedocs.io/en/latest/control-structures.html#order-of-evaluation-of-expressions and given this example:

pragma solidity ^0.4.24;
contract A {
  uint a;
  uint b;
  uint c;

  function init() public{
    a = 10;
    b = 10;
    c = 20;
  }
  function t() public view returns(uint res){
    res = a * b / c;
  }
  
  function u() public returns(uint){
      a += 1;
      return a;
  }
  function v() public returns(uint){
      a += 2;
      return a;
  }
  function w() public returns(uint){
      return u() * v();
  }
}

I understand that the result of

init();
w();

is unspecified, given that either u() or v() could be evaluated first (last I tried, v() was evaluated first).

Is this correct? Adding such an example to the documentation could help.

Similarly, is the result of:

init();
t();

also unspecified? More precisely, given an expression containing operators of equal precedence (* and /), is the evaluation order unspecified, or is it guaranteed to be from left to right?

@chriseth
Copy link
Contributor

chriseth commented Aug 3, 2018

I think we can guarantee the order of evaluation of operators of equal precedence, but the order of side-effecty expressions is not guaranteed.

@Sword-Smith
Copy link

Sword-Smith commented Oct 2, 2018

@chriseth: Can you please add the associativity of operators to the documentation here?
https://solidity.readthedocs.io/en/v0.4.25/miscellaneous.html (assuming that it is well-defined in the compiler which, in my opinion it ought to be.)

@chriseth
Copy link
Contributor

chriseth commented Oct 4, 2018

@Sword-Smith yes, we should!

@chriseth
Copy link
Contributor

I think this has been done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants