assume, assert, enforce, @safe

Daniel Gibson via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 31 10:40:45 PDT 2014


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


More information about the Digitalmars-d mailing list