assert semantic change proposal

[Daniel Gibson via Digitalmars-d]

Am 04.08.2014 02:30, schrieb Andrei Alexandrescu:
> On 8/3/14, 4:01 PM, Timon Gehr wrote:
>> On 08/04/2014 12:15 AM, Andrei Alexandrescu wrote:
>>>> I suspect it is one of those ideas of Walter's that has consequences
>>>> that reach further than anyone foresees..... but that's OK, because it
>>>> is fundamentally the correct course of action, it's implications
>>>> foreseen and unforeseen will be correct.
>>>
>>> Agreed.
>>
>> No, please hold on. Walter is not a supernatural being.
>
> There's something to be said about vision and perspective.
>
>>> Walter has always meant assert the way he discusses it today.
>>
>> This argument has no merit. Please stop bringing it up.
>
> Actually it does offer value: for a large fragment of the discussion,
> Walter has been confused that people have a very different understanding
> of assert than his.

Yes, this kinda helps understanding Walters point.

But as his point has only been communicated to *you*, not D users in 
general, you (and Walter) could be more understanding towards them being 
surprised and confused by this change of asserts()'s semantics.

Instead you insist that your interpretation of what assert() should 
*mean* is the ultimate truth, even though assert() doesn't *behave* like 
that way in current D or any popular programming language I know of.
BTW, TCPL ("KnR") (Second Edition) defines assert as:
"The assert macro is used to add diagnostics to programs:
   void assert(int expression)
If expression is zero when assert(expression) is executed, the assert 
macro will print on stderr a message, (...)
It then calls abort to terminate execution. (...)
If NDEBUG is defined at the time <assert.h> is included, the assert 
macro is ignored."

Of course KnR is not the ultimate truth, but it shows that there have 
been definitions (by clever people!) of assert() that contradict yours 
for a long time.

Cheers,
Daniel