assume, assert, enforce, @safe

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Mon Sep 15 17:33:47 PDT 2014


On Fri, 01 Aug 2014 01:07:55 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, 31 July 2014 at 20:49:18 UTC, Timon Gehr wrote:
>> On 07/31/2014 09:37 PM, Jonathan M Davis wrote:
>>> disable contracts, turn assert(0) into a halt
>>> instruction, and disable bounds checking in @system and @trusted code.
>>> So, if you want to keep the assertions and contracts and whatnot in,
>>
>> Unfortunately, if used pervasively, assertions and contracts and  
>> whatnot may actually hog the speed of a program in a way that breaks  
>> the deal.
>>
>> Disabling assertions (and whatnot), assuming assertions to be true (and  
>> disabling whatnot) and leaving all assertions and whatnot in are  
>> different trade-offs, of which assuming all assertions to be true is  
>> the most dangerous one. Why hide this behaviour in '-release'?
>
> I'm afraid that I don't see the problem. If you want assertions left in  
> in your release/production builds, then don't use -release. If you want  
> them removed, then use -release. Are you objecting to the fact that the  
> compiler can do further optimizations based on the fact that the  
> assertions are presumed to be true if they're removed? I really don't  
> see any problem with that. You're screwed regardless if the assertions  
> would have failed. By their very nature, if an assertion would have  
> failed, your program is an invalid state, so if you don't want to risk  
> having code run that would have failed an assertion, then just don't  
> compile with -release. And if you are willing to assume that the  
> assertions won't fail and have them disabled in your release build, then  
> you might as well gain any extra optimizations that can be made from  
> assuming that the assertion is true. You're already making that  
> assumption anyway and potentially letting your program enter an invalid  
> state.

This is not tenable. I realized when developing a library with classes,  
that not doing -release, means every virtual call is preceded and followed  
by a call to assert(obj), which calls Object.invariant -- a virtual call.  
Even if you don't define any invariant, it's still called (maybe final  
classes are better, but I'm not sure).

The cost for this is tremendous. You may as well not use classes.

-Steve


More information about the Digitalmars-d mailing list