assert semantic change proposal

[David Bregman via Digitalmars-d]

On Sunday, 3 August 2014 at 23:51:30 UTC, 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)?
>
> 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.

Indeed, having a new function instead of hijacking assert would 
seem to be the obvious solution.

That's really interesting about the possibility of conveying 
probabilistic information to the compiler. Of course, we'd need 
different functions for constant axioms and probabilistic ones: 
we could use (for example) assume() for constants and expect() 
for probabilities.