On Wednesday, 6 August 2014 at 01:11:55 UTC, Jeremy Powers via
Digitalmars-d wrote:
That's in the past. This is all about the pros and cons of
changing it now
and for the future.
The main argument seems to revolve around whether this is
actually a change
or not. In my (and others') view, the treatment of assert as
'assume' is
not a change at all. It was in there all along, we just needed
the wizard
to tell us.
How can there be any question? This is a change in the compiler,
a change in the docs, change in what your program does, change of
the very bytes in the executable. If my program worked before and
doesn't now, how is that not a change? This must be considered a
change by any reasonable definition of the word change.
I don't think I can take seriously this idea that someone's
unstated, unmanifested intentions define change more so than
things that are .. you know.. actual real changes.
Much of the rest of your post seems to be predicated on this, so
I don't think I can respond to it. Let me know if I missed
something.
In an attempt to return this discussion to something useful,
question:
If assert means what I think it means (and assuming we agree on
what the
actual two interpretations are), how do we allay concerns about
it? Is
there anything fundamentally/irretrievably bad if we use this
new/old
definition?
Well I think I outlined the issues in the OP. As for solutions,
there have been some suggestions in this thread, the simplest is
to leave things as is and introduce the optimizer hint as a
separate function, assume().
I don't think there was any argument presented against a separate
function besides that Walter couldn't see any difference between
the two behaviors, or the intention thing which doesn't really
help us here.
I guess the only real argument against it is that pre-existing
asserts contain significant optimization information that we
can't afford to not reuse. But this is a claim I'm pretty
skeptical of. Andrei admitted it's just a hunch at this point.
Try looking through your code base to see how many asserts would
be useful for optimizing. For me, it's mostly
default:assert(false); in switch statements, though ironically
that is defined to produce a halt even in release, so the
compiler won't optimize away the branch like it should.
Heh, I just realized, that particular special case is another
argument for a separate function, because assert(false) can't
express unreachability. assume(false) could.
(Can we programmatically (sp?) identify and flag/resolve
issues that occur from a mismatch of expectations?)
I'm not an expert on this, but my guess is it's possible in
theory but would never happen in practice. Such things are very
complex to implement, if Walter won't agree to a simple and easy
solution, I'm pretty sure there's no way in hell he would agree
to a complex one that takes a massive amount of effort.
