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