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?

Tomek

On Tue, 22 Jun 2010 17:07:02 -0400, Tomek Sowiński <just@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

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@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...

Steven Schveighoffer wrote:

> On Tue, 22 Jun 2010 17:07:02 -0400, Tomek Sowiński <just@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

Also IIRC, the compiler uses assert(0) to ensure that functions blow up at runtime if you manage to hit the end of them without a return statement.

And it's not like it hurts anything to make it part of the language. Also, having them as part of the language gives the compiler better control of them and allows it to know more about them in order to treat them in a special manner, which it could not do with library functions.

All in all, there isn't really a downside (as far as I'm aware of anyway) to having them in the language itelf, and it helps the compiler deal with them.

- Jonathan M Davis

Jonathan M Davis wrote:
> Steven Schveighoffer wrote:

>> 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!)

> Also IIRC, the compiler uses assert(0) to ensure that functions blow up at
> runtime if you manage to hit the end of them without a return statement.

I just read in TDPL that the assert(0) calls in user code are not removed even in release mode.

Ali

On 06/22/2010 05:36 PM, Ali Çehreli wrote:
> Jonathan M Davis wrote:
>  > Steven Schveighoffer wrote:
>
>  >> 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!)
>
>  > Also IIRC, the compiler uses assert(0) to ensure that functions blow
> up at
>  > runtime if you manage to hit the end of them without a return statement.
>
> I just read in TDPL that the assert(0) calls in user code are not
> removed even in release mode.
>
> Ali

Really?

// test.d
void main(){
 assert(0);
}

$ dmd test -release
$ ./test
Segmentation fault (core dumped)

good job, dmd. Can anyone see if anything is going on here?

Am 22.06.2010 23:07, schrieb Tomek Sowiñski:
> 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?
>
> Tomek

what about static assert?

Ellery Newcomer wrote:

> On 06/22/2010 05:36 PM, Ali Çehreli wrote:
>> Jonathan M Davis wrote:
>>  > Steven Schveighoffer wrote:
>>
>>  >> 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!)
>>
>>  > Also IIRC, the compiler uses assert(0) to ensure that functions blow
>> up at
>>  > runtime if you manage to hit the end of them without a return statement.
>>
>> I just read in TDPL that the assert(0) calls in user code are not
>> removed even in release mode.
>>
>> Ali
> 
> Really?
> 
> // test.d
> void main(){
>   assert(0);
> }
> 
> $ dmd test -release
> $ ./test
> Segmentation fault (core dumped)
> 
> good job, dmd. Can anyone see if anything is going on here?

According to TDPL, assert(false) is treated specially and never removed. It
serves two purposes:
- portable way of issuing the HLT instruction
- telling the compiles that everything after is dead code, the compiler
recognizes the meaning assert(false)

Dnia 22-06-2010 o 23:55:29 Michal Minich <michal.minich@gmail.com> napisał(a):

> 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@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) {
    version(unittest)
        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 like:

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?


Tomek

Dnia 23-06-2010 o 07:05:42 dennis luehring <dl.soluz@gmx.net> napisał(a):

> Am 22.06.2010 23:07, schrieb Tomek Sowiñski:
>> 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?
>>
>> Tomek
>
> what about static assert?

I was asking about runtime assertions.

But actually, that might be the first decent reason to keep assert as a keyword. Although there's no problem implementing it as in C++ (using specialization of templates), the syntax nicely correlates with static if.


Tomek