digitalmars.D.bugs - [Issue 9482] New: Option to compile in release mode, but keep in contracts on non-private functions
- d-bugmail puremagic.com (47/47) Feb 08 2013 http://d.puremagic.com/issues/...
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