assert semantic change proposal

[David Bregman via Digitalmars-d]

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.