Charlie wrote:
> I dislike how -release strips out contracts, its often valuable to have contracts left in even in a release build.  I believe the front end even has specific flags for disabling contracts and asserts, I don't think Walter accepted the user submitted patch though.

I agree in part.  I think there should be debug, release, and final. Final should have all assets removed but they should remain in release.  If you still want them in final then the user should specify -unittest.

In general I see a release as something you release internally to QA and other users.  Final is something you send to a publisher or to the public.

Another thing.  Often I've seen 3 types of runtime-assets.
assert //debug only
release_assert
final_assert

> 
> And while we're on the topic whatever happen to Gregor's unittest patch ?
> 
> Charlie
> 

Charlie wrote

> its often valuable to have contracts left in even in a release build.

Are you able to give some reasonings for the value that is lost by disabling contracts, when a binary is given into production?

-manfred

Charlie wrote:

> And while we're on the topic whatever happen to Gregor's unittest patch ?

FWIW, Sean committed an alternative solution to the Tango runtime a few days ago.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Derek Parnell wrote:
> On Sun, 27 May 2007 14:15:13 -0400, lurker wrote:
> 
>> What does it mean to compile a file with -debug and -release switches? Like so:
>>
>> $ echo "void main() {}" > test.d
>> $ dmd -debug -release test.d
>>
>> Why the compiler accepts both and doesn't complaint?
> 
> The compiler accepts both because they are not opposites of each other,
> despite what one may think just knowing the English terms.
> 
> "-debug" functionality is almost exactly like the "-version" switch. It
> actually has nothing intrinsic to with debugging other than identifying
> sections of code as ones in which the author nominates, and thus presumably
> intends, to be debugging code. But the code can contain anything at all.
> These sections of code are brought into the compilation process in exactly
> the same way as sections identified using the version construct. In fact,
> one can use "version(XXX){}" and "debug(XXX){}" interchangeably. In other
> words ...
> 
>    debug(ABC) { ... }
> 
> is functionally identical to 
> 
>   version(ABC) { ... }
> 
> The purpose of using "debug" rather than "version" is just to highlight to
> readers of the source code the sections that are intended to be debugging
> stuff. There is nothing 'magic' about "-debug".

> 
> "-release" controls whether or not built-in and user-defined checks are
> excluded from the compilation. If you do not have "-release" the compiler
> adds array bounds checking, assert() functionality, invariant blocks in
> classes, and in/out blocks in functions. If you use "-release" such
> functionality is ignored by the compiler. Presumably the name "release" is
> being associated with the desire to remove time consuming run time checks
> in a program that has been debugged and is ready now for production
> release.

Maybe something like -nochecks would be a better name for -release.
At least, the command line description should change
  -quiet         suppress unnecessary messages
  -release       compile release version

That's really not helpful!

How about:
  -release       do not generate runtime checks

I only just discovered that assert(0) is _not_ disabled by -release. I didn't find that mentioned in the documentation.

Don Clugston Wrote:
> I only just discovered that assert(0) is _not_ disabled by -release. I didn't find that mentioned in the documentation.

Perhaps we want a table of things with the various compile flags which enable/disable them in the docs.  Similar to the comparison table for structs, classes, etc.

Regan Heath

Regan Heath wrote:

> Don Clugston Wrote:
>> I only just discovered that assert(0) is _not_ disabled by -release. I didn't find that mentioned in the documentation.
> 
> Perhaps we want a table of things with the various compile flags which enable/disable them in the docs.  Similar to the comparison table for structs, classes, etc.
> 
> Regan Heath

Until that happens, you can look inside the 'dmd/mars.c' file of the dmd frontend source code. The options parsing happens here and it's fairly easy to follow. For example the -release flag does this:

... snip ...

else if (strcmp(p + 1, "release") == 0)
        global.params.release = 1;

... snip ...

if (global.params.release)
    {   global.params.useInvariants = 0;
        global.params.useIn = 0;
        global.params.useOut = 0;
        global.params.useAssert = 0;
        global.params.useArrayBounds = 0;
        global.params.useSwitchError = 0;
    }