On 05/24/2015 11:26 PM, Jonathan M Davis wrote:
On Sunday, 24 May 2015 at 21:18:54 UTC, Timon Gehr wrote:
The gcc backend obviously supports ordered operations, because some
operations are ordered today.
Iain has talked in the past about how they're forced to work around the
backend to force the order of operations for those cases, and it's
definitely ugly.
...
Given that it is/should be already there for OrExpression,
XorExpression, AndExpression, CmpExpression, ShiftExpression,
AddExpression, CatExpression, MulExpression, PowExpression,
OrOrExpression, AndAndExpression, it would seem that doing the few
remaining cases left-to-right shouldn't be that much of an obstacle, no?
No. Seriously. Under the current semantics, running an exhaustive
input-output test on a fully @safe program will not ensure that the
code is actually correct. Talk about providing a false sense of security.
@safe definitely has issues. We went about it the wrong way by
effectively implementing it via a blacklist instead of a whitelist. And
it needs to be fixed. But as far as the code actually being correct
goes, @safe isn't guaranteed to prove that anyway. All it's supposed to
guarantee is that you can't corrupt memory.
You missed the more relevant exhaustive input-output test part. @safe
was there simply to ensure there is no UB.
