assert semantic change proposal

[Daniel Gibson via Digitalmars-d]

Well, this is not just about branch prediction, but about "let the 
compiler assume the condition is always true and let it eliminate code 
that handles other cases".

I /think/ that in C with GCC assume() could be implemented (for release 
mode, otherwise it's just like assert()) like
   #define assume(cond) if(!(cond)) __builtin_unreachable()
I'm not sure what kind of optimizations GCC does based on "unreachable", 
though.

However, something like expect() /might/ be a useful addition to the 
language as well. Maybe as an annotation for if()/else?

Cheers,
Daniel

Am 04.08.2014 01:51, schrieb Mike Farnsworth:
> 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)?
>
> That way you don't have to hijack the meaning of assert(), but
> optimizations can be made based on the condition. __buitin_expect() in
> gcc usually just figures the expected condition is fulfilled the vast
> majority of the time, but it could be expanded to make a lack of
> fulfillment trigger an exception (in non-release mode).  And the
> compiler is always free to optimize with the assumption the expectation
> is met.
>
> On Sunday, 3 August 2014 at 19:47:27 UTC, David Bregman wrote:
>> I am creating this thread because I believe the other ones [1,6] have
>> gotten too bogged down in minutiae and the big picture has gotten lost.
>>
>> ...
>>
>> References:
>> [1]: http://forum.dlang.org/thread/lrbpvj$mih$1@digitalmars.com
>> [2]: http://dlang.org/overview.html
>> [3]:
>> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
>> [4]: http://blog.regehr.org/archives/213
>> [5]: http://en.wikipedia.org/wiki/Heisenbug
>> [6]: http://forum.dlang.org/thread/jrxrmcmeksxwlyuitzqp@forum.dlang.org