Why assert is in the language?

Tomek Sowiński just at ask.me
Wed Jun 23 13:06:48 PDT 2010

Dnia 22-06-2010 o 23:55:29 Michal Minich <michal.minich at gmail.com>  

> On Tue, 22 Jun 2010 17:30:23 -0400, Steven Schveighoffer wrote:
>> On Tue, 22 Jun 2010 17:07:02 -0400, Tomek Sowiński <just at ask.me> wrote:
>>> Yes, why? It could be implemented in object.d in a similar fashion as
>>> std.contracts.enforce. Does it do anything special that a library
>>> function couldn't?
>> all calls to assert are removed by the compiler in release mode.  I
>> don't think there's a way to implement that via a library (it would be
>> nice though!)
>> -Steve
> modifying 'debug' attribute which decorate a function, which new meaning
> that all calls to it are removed in release mode, might do the trick :)
> it also could be useful for logging.
> AFAIK, now the attribute means that the function does not exists in debug
> mode, but that also means that you must mark all calls to it with 'debug'
> which I don't find so much useful...

There's a better way:

void assert_(string file = __FILE__, uint line = __LINE__)(bool pred, lazy  
string msg = null) {
         if (!pred)
             throw new AssertError(msg, file, line);

If unittesting is off, it is inlined and all calls vanish.

Someone mentioned the assert(0) special case. That could be implemented  

void fail() {
     asm {
          // HLT instruction...

Following benefits spring to mind:
  - It's clear that fail is something different than assert. Unlike assert  
vs. assert(0).
  - The compiler can be made aware of fail() to recognize and refuse to  
compile dead code.
  - Documentation can be added with no additional effort; newbies can read  
it straight from a tooltip provided by the IDE.
  - Curious users are free to introspect the implementation.

So I ask again -- what benefits on top of that list can having assert in  
the language give?


More information about the Digitalmars-d-learn mailing list