https://issues.dlang.org/show_bug.cgi?id=14364

Shammah Chancellor <shammah.chancellor@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|DMD should compile SDC      |DMD should compile
                   |test0167.d                  |(correctly) SDC test0167.d

--

https://issues.dlang.org/show_bug.cgi?id=14364

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |ag0aep6g@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=14364

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from ag0aep6g@gmail.com ---
(In reply to Shammah Chancellor from comment #0)
> 	int ret = 5;
> 	ret += ((ret++ == 5) ? (ret += 3) : (ret -= 11)) + ret;
> 	assert(ret == 23);

To arrive at 23 I guess sdc see these values:

5   +                   6   +  3                 + 9 = 23
ret += ((ret++ == 5) ? (ret += 3) : (ret -= 11)) + ret;

That is, sdc takes the value of the lhs before evaluating the rhs.

dmd arrives at 27 = 9 + 6 + 3 + 9, meaning it evaluates the rhs before taking the value of the lhs.

The spec has something to say about that[1]:
> The following binary expressions are evaluated in an implementation-defined order:
> 
> AssignExpression, function arguments
> 
> It is an error to depend on order of evaluation when it is not specified. For example, the following are illegal:
>
> i = i++;

So, both sdc and dmd are right and the test case is "illegal". Closing as invalid.

[1] http://dlang.org/expression.html

--

https://issues.dlang.org/show_bug.cgi?id=14364

--- Comment #2 from Shammah Chancellor <shammah.chancellor@gmail.com> ---
So should this not compile? Isn't this at least a DLang Spec problem?

--

https://issues.dlang.org/show_bug.cgi?id=14364

--- Comment #3 from ag0aep6g@gmail.com ---
(In reply to Shammah Chancellor from comment #2)
> So should this not compile?

Reading that spec page further:
> If the compiler can determine that the result of an expression is illegally dependent on the order of evaluation, it can issue an error (but is not required to). The ability to detect these kinds of errors is a quality of implementation issue.

So, compilers are encouraged to reject such code, but they can also accept it and evaluate the sides of the assignment in either order.

> Isn't this at least a DLang Spec problem?

Feel free to file an enhancement request to specify one true order of evaluation for AssignExpression.

--

https://issues.dlang.org/show_bug.cgi?id=14364

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #4 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
actually, compiler must warn about sequence point error. but DMD is for smarts, so it does it's best to carefully hide such errors from programmer.

--

https://issues.dlang.org/show_bug.cgi?id=14364

deadalnix <deadalnix@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |deadalnix@gmail.com
         Resolution|INVALID                     |---

--- Comment #5 from deadalnix <deadalnix@gmail.com> ---
Reopening. The spec is wrong. It has been discussed many time that should have LTR semantic.

--

https://issues.dlang.org/show_bug.cgi?id=14364

--- Comment #6 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to deadalnix from comment #5)
> Reopening. The spec is wrong. It has been discussed many time that should have LTR semantic.

Can you list the links to the discussions?

--

https://issues.dlang.org/show_bug.cgi?id=14364

--- Comment #7 from deadalnix <deadalnix@gmail.com> ---
(In reply to Kenji Hara from comment #6)
> (In reply to deadalnix from comment #5)
> > Reopening. The spec is wrong. It has been discussed many time that should have LTR semantic.
> 
> Can you list the links to the discussions?

So I reached to Andrei to know the exact details. It turns out this is a point where Andrei and Walter are not in agreement.

Andrei advocate for LTR all the way down (as SDC do) and Walter does seems to be inclined to specify it precisely for calls.

Anyway, as per spec, a += k is rewritten as

a = cast(typeof(a)) (a + k);

See http://dlang.org/expression.html, Assignment Operator Expressions for reference.

So I think that, even by Walter's standards, as this is not a call, this should be well defined.

--

https://issues.dlang.org/show_bug.cgi?id=14364

--- Comment #8 from deadalnix <deadalnix@gmail.com> ---
(In reply to Kenji Hara from comment #6)
> (In reply to deadalnix from comment #5)
> > Reopening. The spec is wrong. It has been discussed many time that should have LTR semantic.
> 
> Can you list the links to the discussions?

So I reached to Andrei to know the exact details. It turns out this is a point where Andrei and Walter are not in agreement.

Andrei advocate for LTR all the way down (as SDC do) and Walter does seems to be inclined to specify it precisely for calls.

Anyway, as per spec, a += k is rewritten as

a = cast(typeof(a)) (a + k);

See http://dlang.org/expression.html, Assignment Operator Expressions for reference.

So I think that, even by Walter's standards, as this is not a call, this should be well defined.

I opened a thread on the newgroup: http://forum.dlang.org/thread/dqkqvnkgxkxncyvyitid@forum.dlang.org#post-dqkqvnkgxkxncyvyitid:40forum.dlang.org

--