The case of -debug -O and: is breaking pure/@nogc/nothrow/@safe UB under -debug?

Nicholas Wilson iamthewilsonator at hotmail.com
Wed Apr 18 13:40:29 UTC 2018


On Wednesday, 18 April 2018 at 13:15:08 UTC, Guillaume Piolat 
wrote:
> The D specification says:
>
> "A ConditionalStatement that has a DebugCondition is called a 
> DebugStatement. DebugStatements have relaxed semantic checks in 
> that pure, @nogc, nothrow and @safe checks are not done. 
> Neither do DebugStatements influence the inference of pure, 
> @nogc, nothrow and @safe attributes."
>
>
> So it seems under a debug clause you don't have to conform to 
> pure/@nogc/nothrow/@safe.

Correct. Good luck trying to debug a pure function if you can't 
print intermediates.
>
> The immediate question that follow is:
>
> "Is breaking pure/@nogc/nothrow/@safe Undefined Behaviour (UB) 
> in a DebugStatement?"

Pure: definitely no, debug escaping pure is pretty much the whole 
point.
@nogc/nothrow/@safe I'm not so sure about. I think it is allowed 
because logging functions may not necessarily be 
@nogc/nothrow/@safe and not being able to call them  defeats the 
purpose of debug.

> Would the optimizer -O breaks code that breaks such by virtue 
> of being -debug?

I don't think so:
pure: optimisations are about eliding calls with identical 
arguments. You shouldn't be relying on any variations due to 
optimisation
@nogc: no optimisation are performed based on this knowledge.
nothrow: optimisations are about eliding unwinding tables, I 
don't think this would have an effect on the soundness of the 
function.
@safe: debug is effectively @trusted, the usual rules apply.



More information about the Digitalmars-d-learn mailing list