assume, assert, enforce, @safe

[John Colvin via Digitalmars-d]

On Thursday, 31 July 2014 at 17:40:45 UTC, Daniel Gibson wrote:
> Am 31.07.2014 18:29, schrieb Andrei Alexandrescu:
>> On 7/31/14, 8:37 AM, Daniel Gibson wrote:
>>> When I tell it to write something, I want it to do that, even 
>>> if it
>>> might look like nonsense (if anything, it could create a 
>>> warning).
>>
>> I'm afraid those days are long gone by now. -- Andrei
>
> At least for C..
> It sucks not to be able to predict the behavior of sane-looking 
> code without knowing the language standard in all details by 
> heart.
>
> I'd prefer if D  only did optimizations that are safe and don't 
> change the behavior of the code and thus was less painful to 
> use than C and C++ that need deep understanding of complicated 
> standards to get right ("the last thing D needs is someone like 
> Scott Meyers"?)
>
> Examples for eliminations that I'd consider safe:
> * if something is checked twice (e.g. due to inlining) it's 
> okay to only keep the first check
> * if a variable is certainly not read before the first 
> assignment, the standard initialization could be optimized 
> away.. same for multiple assignments without reads in between, 
> *but*
>  - that would still look strange in a debugger when you'd 
> expect another value
>  - don't we have int x = void; to prevent default 
> initialization?
> * turning multiplies into shifts and additions is totally fine 
> if it does not change the behavior, even in corner cases.
> * optimizing out variables
>
> It's a major PITA to debug problems that only happen in release 
> builds.
>
> Cheers,
> Daniel

I believe gdc has the full suite of gcc optimiser flags 
available. You don't need to just slap -O3 on and then complain 
about the changes it makes, you can choose with a reasonable 
amount of precision which optimisations you do/don't want done.