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