assert semantic change proposal

[via Digitalmars-d]

On Wednesday, 6 August 2014 at 01:11:55 UTC, Jeremy Powers via 
Digitalmars-d wrote:
>> That's in the past. This is all about the pros and cons of 
>> changing it now
>> and for the future.
>>
>
> The main argument seems to revolve around whether this is 
> actually a change
> or not.  In my (and others') view, the treatment of assert as 
> 'assume' is
> not a change at all.  It was in there all along, we just needed 
> the wizard
> to tell us.

This is already the first misunderstanding: The argument is about 
whether it's a good idea, not whether it's newly introduced or 
has been the intended meaning since assert's conception.

>
>
>
> The below can safely be ignored, as I just continue the pedantic
> discussions....
>
>
> OK, but my point was you were using a different definition of 
> undefined
>> behavior. We can't communicate if we aren't using the same 
>> meanings of
>> words.
>>
>>
> Yes, very true.  My definition of undefined in this case hinges 
> on my
> definition of what assert means.  If a failed assert means all 
> code after
> it is invalid, then by definition (as I interpret the 
> definition) that code
> is invalid and can be said to have undefined behaviour.  That 
> is, it makes
> sense to me that it is specified as undefined, by the spec that 
> is
> incredibly unclear.  I may be reading too much into it here, 
> but this
> follows the strict definition of undefined - it is undefined 
> because it is
> defined to be undefined.  This is the 'because I said so' 
> defense.

Of course you can define your own concept and call it 
"undefined", but I don't see how it matters. The concept 
described by the usual definition of "undefined" still exists, 
and it still has very different implications than your concept 
has. To give a more practical example:

You're writing an authentication function. It takes a username 
and a password, and returns true or false, depending on whether 
the password is correct for this username. Unfortunately, the 
verification algorithm is wrong: due to an integer overflow in 
the hash calculation, it rejects some valid passwords, but never 
accepts invalid ones. The program is clearly incorrect, but its 
behaviour is still well-defined and predictable (overflow is not 
undefined in D).

Now, if the flaw in the algorithm were due to an actual undefined 
operation, everything could happen, including the function 
accepting invalid passwords. I hope it's clear that this is a 
very different class of brokenness.

> My stance is that this new/old definition is a good thing, as 
> it matches
> how I thought things were already, and any code that surfaces 
> as broken
> because of it was already broken in my definition.  Therefore 
> this 'change'
> is good, does not introduce breaking changes, and arguments 
> about such
> should be redirected towards mitigation and fixing of 
> expectations.
>
> In an attempt to return this discussion to something useful, 
> question:
>
> If assert means what I think it means (and assuming we agree on 
> what the
> actual two interpretations are), how do we allay concerns about 
> it?  Is
> there anything fundamentally/irretrievably bad if we use this 
> new/old
> definition?  (Can we programmatically (sp?) identify and 
> flag/resolve
> issues that occur from a mismatch of expectations?)

My understanding (which is probably the same as that of most 
people participating in the discussion, because as I said above, 
I _don't_ think the argument is about a misunderstanding on this 
level):

Walter's assert:
* Expresses a statement that the programmer intends to be true. 
It is only checked in non-release mode.
* The compiler can assume that it is true - even in release mode 
- because the programmer explicitly said so, and the compiler may 
not have figured it out by itself (similar to casts, which also 
express assumptions by the programmer that the compiler cannot 
know otherwise).
* Asserting a condition that is false is undefined behaviour.

The other assert:
* Expresses a statement that the programmer intends to be true. 
It is only checked in non-release mode.
* Because it is unlikely that the programmer has proved the 
correctness in the general case, the compiler must not assume it 
is true unless it can prove it to be, either at compile time, or 
with a runtime check. Release mode disables the runtime checks.
* Asserting a condition that is false either raises an error at 
runtime, aborts compilation, or doesn't do anything. It never 
causes undefined behaviour by itself.

As I already wrote elsewhere, an assert with the 
suggested/intended behaviour is a very dangerous tool that should 
not be used as widely as it is today. If the asserted condition 
is wrong (for whatever reason), it would create not just wrong 
behaviour, but undefined behaviour (as described above, not your 
concept).

H.S. Teoh however suggested to extend compile time checking for 
assertions. I believe this is the way to go forward, and it has 
great potential. What I don't agree with, of course, is to just 
believe anything in the assertions to be true without verifying 
it.