assert semantic change proposal

[deadalnix via Digitalmars-d]

On Monday, 4 August 2014 at 02:56:35 UTC, David Bregman wrote:
> 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.

The fact that the compiler can optimize based on assert is not 
new in D world. Maybe it wasn't advertized properly, but it 
always was an option.

If one want to make sure a check is done, one can use expect.