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.
