Comment #0 by bearophile_hugs — 2014-01-29T08:25:00Z
I suggest to statically disallow code like this, that is to disallow side effects in assert(), that are source of bugs (because the code can act differently in release mode):
int foo(ref int y) pure nothrow {
return y++;
}
void main() {
int x;
assert(++x);
assert(foo(x));
}
Comment #1 by andrej.mitrovich — 2014-01-30T01:49:47Z
It might be controversial, however I do remember someone actually running into this bug in #d last year.
Comment #2 by tcdknutson — 2014-02-03T14:01:09Z
Andrej, I believe that was me! It would have been nice to have that code checked for side effects in assert statements. I'm in support of this enhancement request.
Comment #3 by bearophile_hugs — 2014-02-03T14:33:11Z
A discussion thread:
http://forum.dlang.org/thread/[email protected]
A problem raised by Brad Roberts:
> I have one semi-large code base where I validate the locking semantics
> by adding assert(!lock.try_acquire)'s. That's clearly a side effect,
> but also clearly should never have one if the code is correct.
And an answer by Marco Leise:
> Basically lock.try_acquire is pure when it returns false, and if not,
> the program is terminated anyways so it doesn't make a difference.
Comment #4 by b2.temp — 2023-06-29T08:21:45Z
*** Issue 24021 has been marked as a duplicate of this issue. ***
Comment #5 by robert.schadek — 2024-12-13T18:16:27Z