assert semantic change proposal

[Jeremy Powers via Digitalmars-d]

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.

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.


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.



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.


 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140805/7e1dddef/attachment-0001.html>