assert semantic change proposal

David Bregman via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 19:56:34 PDT 2014


On Monday, 4 August 2014 at 02:40:49 UTC, deadalnix wrote:
> I allow myself to chime in. I don't have much time to follow 
> the whole thing, but I have this in my mind for quite a while.
>
> First thing first, the proposed behavior is what I had in mind 
> for SDC since pretty much day 1. It already uses hint for the 
> optimizer to tell it the branch won't be taken, but I 
> definitively want to go further.

Not everyone had that definition in mind when writing their 
asserts.

> By definition, when an assert has been removed in release that 
> would have failed in debug, you are in undefined behavior land 
> already. So there is no reason not to optimize.

By the new definition, yes. But is it reasonable to change the 
definition, and then retroactively declare previous code broken? 
Maybe the ends justify the means in this case but it certainly 
isn't obvious that they do. I don't understand why breaking code 
is sacrilege one time, and the next time can be done without any 
justifications.


More information about the Digitalmars-d mailing list