On Wednesday, 6 August 2014 at 01:39:25 UTC, Mike Parker wrote:
On 8/6/2014 8:18 AM, David Bregman wrote:
You keep going on the premise that your definition is the
intended definition. I completely disagree. My understanding of
assert has always been as Walter has described it.
I did not use to think the same, but once Walter stated his
vision of assert(), it was like a kind of revelation to me: why
the optimizer won't make use of such obvious information like
assert() provides just like asimple:
if(x<5) {
// you can safely optimize this code knowing (*assuming*)
that always x<5
}
But, what started to bother me lately and, I think, is the root
of the problem: to have programmer code disabled by a compiler
flag. I do not speak about boundschecking, where the code is
never explicitely written by the programmer, but of real
programmer code.
Until now, versioning (or, in C/C++, the #ifdef) was the sole
acceptable way to disable programmer code. The C assert slipped
through as being based on a #ifdef or #if (I know good compilers
will also optimize a if(0), but this is just because it happens
to be obvious).
OTOH, the D assert is no longer based (directly) on versioning,
so having it disabled by a flag is not easily grasped. This,
combined with the sudden revelation of the optimizer messing with
it, produced a shock and this thread illustrates it. People are
just to used to its secondary meaning from C, that is, besides
testing conditions: "easily obtain a log of what and where was
wrong". So, it was an assertion, but also a logging feature
(albeit a fatal one). People got used with assert() becoming noop
code in the release mode, just like they would disable the logs
for release.
The more I think about it, the more I feel like assert would be
more naturally an annotation or a kind of versioning. Still, I
cannot come with a clear cut proposition, as my mind is also
entangled in old habits. One one hand, it feels natural as an
instruction, on the other hand, being disable-able, maybe even
ignorable (in release builds) and an invalidating point for the
program logic*, it should belong somewhere else.
*I think this is important: is not only a tested condition that
is then handled, but a tested condition exposing a "does not work
as intended". It looks more like a kind of "this code should be
unreachable".
