"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bjh9r7$2itd$1@digitaldaemon.com...
> "Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjbrk0$kua$2@digitaldaemon.com...
> > static_assert() would:
> >   - not issue code under any circumstances. It's entirely compile-time
> >   - issue a compile-time warning if the invariant was invalid. It would
> > provide a meaningful message. (For those of you that have used
ct-asserts
> in
> > C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
> > stuff isn't perfect.)
> >   - issue a rejection, plus appropriately distinct (i.e. from from
> invariant
> > invalidity) message if the code is run-time evaluable.
>
> I'm with you, except that I think that a failed assertion should issue an error instead of a warning. If you remember Walter's Web page on the
origin
> of D, well, I'm one of those who enable maximum warning level and have the compiler stop on warnings... :)

Sorry. I hadn't realised I'd written that. I most certainly do not want a warning. I should have written

   - issue a compile-time *error* if the invariant was invalid. It would
provide a meaningful message. (For those of you that have used ct-asserts in
C or C++, it's filthy stuff. Even Andrei Alexandrescu's stuff (C++ only)
stuff isn't perfect.)
   - issue an *error*, plus appropriately distinct (i.e. from from invariant
invalidity) message if the code is run-time evaluable.

As I've followed this discussion, I've seen where a built-in assert() is indeed
useful if it will work at compile-time. However I'm still of the opinion that
the developer should be able to define his own assert(), at least for run-time.
My earlier comment that I want to specify _what_ information is logged when an
assert() fails still holds, but I remembered that I also want to specify _where_
that information is logged.
I prefer to log to stderr rather than stdout (remember, I'm an OpenVMS kind of
guy). And on my last job, log messages where actually sent across the network to
a server that was monitored by tech support 24/7.

John Boucher
The King had Humpty pushed.

I agree. Run-time assert should be pluggable.

"John Boucher" <John_member@pathlink.com> wrote in message news:bjid13$15s8$1@digitaldaemon.com...
> As I've followed this discussion, I've seen where a built-in assert() is
indeed
> useful if it will work at compile-time. However I'm still of the opinion
that
> the developer should be able to define his own assert(), at least for
run-time.
> My earlier comment that I want to specify _what_ information is logged
when an
> assert() fails still holds, but I remembered that I also want to specify
_where_
> that information is logged.
> I prefer to log to stderr rather than stdout (remember, I'm an OpenVMS
kind of
> guy). And on my last job, log messages where actually sent across the
network to
> a server that was monitored by tech support 24/7.
>
> John Boucher
> The King had Humpty pushed.

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bjj58f$2a81$1@digitaldaemon.com...
> I agree. Run-time assert should be pluggable.

Absolutely. My target systems hardly have a console at all, go figure!

Ric

"Sean L. Palmer" <palmer.sean@verizon.net> a écrit dans le message de news:bjd0f6$2edn$1@digitaldaemon.com...
> How about:
>
> if (!condition)
>     bomb("assert %d failed on object %.s", ptr, obj.name());
>
> Ok, you could call it error, or whatever.  It could even be an exception class that you have to throw.  The nice thing about this is that if() is already done at compile time if the argument is a constant expression.
It's
> a bit more explicit than assert, and more versatile.   If the compiler detects an unhandled throw that will always happen maybe it could show an error at compile time.

But some compiler gives a warning if a conditionnal expression is always true...

Maybe the solution would be to uses a modifier to tag static, run-time (and
both)
assertion functions so that the compiler will knows the purpose but the user
would be able to provide as many functions as he would like and we could
even add an optionnal clause that would give a condition when the assertion
is checked (maybe, this could be done with version)

And as in my previous message, I think that the variable arguments that are output as a string would be very nice particulary if it also works at run-time.

And it should also be possible to pass information like __FILE__ and __LINE__.

So something similar to that

runtime assert(__FILE__ as string f, __LINE__ as int l, bool cond, ... as
string s)
{
    // Do what you want here...
}

where s is a string from concatenation of all arguments so that we can
for example write some values that are used in the expression when it fails
and that both at compile or run-time.

For static assertion, the body would be empty and the compiler would write the messsage that would include the string s.

compiletime static_assert(bool cond, ... as string s)
{    // empty body (or only declaration)
}

We could have both overload if we want more customization of the message (for ex. internationalisation of run-time errors with multiples arguments).

>
> I still think we need a form of sprintf that produces a D string, so we won't have so many copies of the same printf functionality.
>

But for the assertion purpose, I think that variable arguments converted to string in order would be a good way since it is simple and safe...

"J Anderson" <anderson@badmama.com.au.REMOVE> wrote in message news:bj7bls$a1d$1@digitaldaemon.com...
> I'd be nice if the compiler could use normal assertions as static assertions when it identifies that the assertion parameters are constant.

That's a good thought, but it would be hard to make it not trip for things like:

    if (somecondition)
        assert(0);

when the flow of control is not known at compile time.