www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9482] New: Option to compile in release mode, but keep in contracts on non-private functions

http://d.puremagic.com/issues/show_bug.cgi?id=9482

           Summary: Option to compile in release mode, but keep in
                    contracts on non-private functions
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: contracts
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: smjg iname.com


--- Comment #0 from Stewart Gordon <smjg iname.com> 2013-02-08 04:50:21 PST ---
At the moment, development vs. release mode is a binary switch.

Development build (no -release):
- asserts are compiled in
- in/out contracts are compiled in
- invariants are compiled in
- array bounds checking

Release build (-release):
- asserts are ignored
- in/out contracts are ignored
- invariants are ignored
- no array bounds checking

This all-or-nothing choice is unideal.  In particular, for compiling libraries,
it would be useful to still have the in contracts and the asserts therein, but
otherwise have a release build.  This means that the tested and released
library code will perform at (almost) full speed and have minimal code bloat,
but users of the library still get the checks that they are passing valid input
to the library's functions.

Of course, there's no point having the in contracts on private functions, since
these will be called only from within the library.  The same applies to
package.  But for public and protected functions, the in contract would be
generated in this mode.

This would become a non-issue if we:
- move in contract checking to the caller side, as has been suggested on a
number of occasions
- in some way make sure the in contract can be compiled with code that uses the
library, if it isn't present in the .lib
- allow contracts to be specified without an implementation (issue 6549)

But since these changes don't seem to be forthcoming, the improvement I am
suggesting here might be worth implementing at this time.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013