On Tuesday, 5 August 2014 at 18:35:32 UTC, Walter Bright wrote:
(limited connectivity for me)
For some perspective, recently gcc and clang have introduced
optimizations based on undefined behavior in C/C++. The
undefined behavior has been interpreted by modern optimizers as
"these cases will never happen". This has wound up breaking a
significant amount of existing code. There have been a number
of articles about these, with detailed explanations about how
they come about and the new, more correct, way to write code.
The emerging consensus is that the code breakage is worth it
for the performance gains.
That said, I do hear what people are saying about potential
code breakage and agree that we need to address this properly.
Well, then at least we agree there is some kind of tradeoff being
made here if the definition of assert is changed: potential
performance vs a bunch of negatives.
In my estimation, the upside is small and the tradeoff is not
close to being justified. If performance is a top goal, there are
many other things that could be done which have lesser (or zero)
downsides. Just to give one example, addition of a forceinline
attribute would be of great assistance to those attempting to
micro optimize their code.
And of course, adding this as a new function instead of
redefining an existing one would eliminate the code breakage and
C compatibility issues. The undefined behavior issue would
remain, but at least defining assume as @system would alleviate
the @safe issue somewhat (there could still be leaks due to
inlining), and make it more clear to users that it's a dangerous
feature. It would also make it more searchable, for code auditing
purposes.
Anyways, if I have at least made you and others aware of all the
downsides, and all the contradictions of this proposal with D's
stated goals, then I guess I have done my part for this issue.
