assert semantic change proposal

[Mike Farnsworth via Digitalmars-d]

On Monday, 4 August 2014 at 00:34:30 UTC, Andrei Alexandrescu 
wrote:
> On 8/3/14, 4:51 PM, Mike Farnsworth wrote:
>> This all seems to have a very simple solution, to use 
>> something like:
>> expect()
>>
>> GCC for example has an intrinsic, __builtin_expect() that is 
>> used to
>> notify the compiler of a data constraint it can use in 
>> optimization for
>> branches.  Why not make something like this a first-class 
>> citizen in D
>> (and even expand the concept to more than just branch 
>> prediction)?
>
> __builtin_expect is actually not that. It still generates code 
> when the expression is false. It simply uses the static 
> assumption to minimize jumps and maximize straight execution 
> for the true case. -- Andrei

Yes, that's  why I pointed out expanding it to actually throw an 
exception when the expectation isn't meant.  I guess that's 
really more like assume() that has been mentioned?

At EA we used two versions of an assertion: assert() which 
compiled out in non-debug builds, etc; and verify() that was kept 
in non-debug builds but just boiled back down to the condition.  
The latter was when we relied on the side-effects of the logic 
(used the condition in a real runtime branch), but really we 
wanted to know if it ever took the else so to speak as that was 
an error we never wanted to ship with.

FFIW, at my current job, in C++ we use assert() that compiles out 
for final builds (very performance-driven code, so even the 
conditions tested have to scat), and we also have likely() and 
unlikely() macros that take advantage of __builtin_expect().  
There are only a few places where we do both, where the assertion 
may be violated and we still want to recover nicely from it, but 
still don't want the performance suck of the else case code 
polluting the instruction cache.