On Tuesday, 5 August 2014 at 18:19:00 UTC, Jeremy Powers via
Digitalmars-d wrote:
This has already been stated by others, but I just wanted to
pile on - I
agree with Walter's definition of assert.
2. Semantic change.
The proposal changes the meaning of assert(), which will
result in
breaking existing code. Regardless of philosophizing about
whether or not
the code was "already broken" according to some definition of
assert, the
fact is that shipping programs that worked perfectly well
before may no
longer work after this change.
Disagree.
Assert (as I always understood it) means 'this must be true, or
my program
is broken.' In -release builds the explicit explosion on a
triggered
assert is skipped, but any code after a non-true assert is, by
definition,
broken. And by broken I mean the fundamental constraints of
the program
are violated, and so all bets are off on it working properly.
A shipping program that 'worked perfectly well' but has
unfulfilled asserts
is broken - either the asserts are not actually true
constraints, or the
broken path just hasn't been hit yet.
This is the 'already broken' argument, which I mentioned in the
quote above.
This kind of change could never be made in C or C++, because
there is too much legacy code that depends on it. Perhaps D can
still afford to break this because it's still a young language.
That is a strength of young languages. If you believe in this
case that the upside justifies the breakage, by all means, just
say so and accept the consequences. Don't try to escape
responsibility by retroactively redefining previously working
code as broken :)
Looking at the 'breaking' example:
assert(x!=1);
if (x==1) {
...
}
If the if is optimized out, this will change from existing
behaviour. But
it is also obviously (to me at least) broken code already. The
assert says
that x cannot be 1 at this point in the program, if it ever is
then there
is an error in the program.... and then it continues as if the
program were
still valid. If x could be one, then the assert is invalid
here. And this
code will already behave differently between -release and
non-release
builds, which is another kind of broken.
Not everything that breaks will be so obvious as that. It can get
much more hairy when assumptions propagate across multiple levels
of inlining.
Also, some code purposely uses that pattern. It is (or rather,
was) valid for a different use case of assert.
3a. An alternate statement of the proposal is literally "in
release mode,
assert expressions introduce undefined behavior into your code
in if the
expression is false".
This statement seems fundamentally true to me of asserts
already,
regardless of whether they are used for optimizations. If your
assert
fails, and you have turned off 'blow up on assert' then your
program is in
an undefined state. It is not that the assert introduces the
undefined
behaviour, it is that the assert makes plain an expectation of
the code and
if that expectation is false the code will have undefined
behaviour.
This is not the standard definition of undefined behavior.
With regular assert, execution is still well defined. If you want
to know what happens in release mode when the assert condition is
not satisfied, all you need to do is read the source code to find
out.
With assume, if the condition is not satisfied, there is no way
to know what will happen. _anything_ can happen, it can even
format your hard drive. That's true undefined behavior.
3b. Since assert is such a widely used feature (with the
original
semantics, "more asserts never hurt"), the proposal will
inject a massive
amount of undefined behavior into existing code bases, greatly
increasing
the probability of experiencing problems related to undefined
behavior.
I actually disagree with the 'more asserts never hurt'
statement. Exactly
because asserts get compiled out in release builds, I do not
find them very
useful/desirable. If they worked as optimization hints I might
actually
use them more.
And there will be no injection of undefined behaviour - the
undefined
behaviour is already there if the asserted constraints are not
valid.
This uses your own definition of UB again, it isn't true for the
regular definition.
Maybe if the yea side was consulted, they might easily agree
to an
alternative way of achieving the improved optimization goal,
such as
creating a new function that has the proposed semantics.
Prior to this (incredibly long) discussion, I was not aware
people had a
different interpretation of assert. To me, this 'new
semantics' is
precisely what I always thought assert was, and the proposal is
just
leveraging it for some additional optimizations. So from my
standpoint,
adding a new function would make sense to support this
'existing' behaviour
that others seem to rely on - assert is fine as is, if the
definition of
'is' is what I think it is.
That doesn't mean you don't have buggy asserts in your code, or
buggy assers in libraries you use (or the standard library), so
you are not immune from undefined behavior.
