>> What's wrong with static_assert()? If it's ugly, I have no problem with
that
>> (static_cast, reinterpret_cast, etc.).

>static_assert is fine with me, what is not neat is stlsoft_static_assert.

Well, in D we don't have the spectre of the global namespace polluting macro preprocessor to worry about, so static_assert is fine. When you're dealing with C/C++, you absolutely have to make your macros practically clash-proof, hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_

:)

"Matthew Wilson" <matthew@stlsoft.org> a écrit dans le message de news:bj9fa4$bnr$1@digitaldaemon.com...
> >> What's wrong with static_assert()? If it's ugly, I have no problem with
> that
> >> (static_cast, reinterpret_cast, etc.).
>
> >static_assert is fine with me, what is not neat is stlsoft_static_assert.
>
> Well, in D we don't have the spectre of the global namespace polluting
macro
> preprocessor to worry about, so static_assert is fine. When you're dealing with C/C++, you absolutely have to make your macros practically
clash-proof,
> hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_
>
> :)
>
>

A better solution would be to provide some knid of module/namespace concept for C imported stuff... so it would be C names that would be uglier and not the D ones...

The best thing would be import with the possibility to qualify imported names (see also .h to D conversion thread).

Philippe Mori wrote:

> A better solution would be to provide some knid of module/namespace
> concept for C imported stuff... so it would be C names that would be
> uglier and not the D ones...

You haven't really read this thread, have you? :)
It's technically impossible (and infeasible) to import stlsoft_static_assert into D, however hard you try! :)
Nor is it possible to import any template library at all...
It was about adding the language feature.

> The best thing would be import with the possibility to qualify imported
> names (see also .h to D conversion thread).

Why the hell? D forces modules on *everything*...
Each source file is in a separate namespace.

-eye

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bjb2ug$2kjk$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> a écrit dans le message de news:bj9fa4$bnr$1@digitaldaemon.com...
> > >> What's wrong with static_assert()? If it's ugly, I have no problem
with
> > that
> > >> (static_cast, reinterpret_cast, etc.).
> >
> > >static_assert is fine with me, what is not neat is
stlsoft_static_assert.
> >
> > Well, in D we don't have the spectre of the global namespace polluting
> macro
> > preprocessor to worry about, so static_assert is fine. When you're
dealing
> > with C/C++, you absolutely have to make your macros practically
> clash-proof,
> > hence the ugly (to you, naturally its beautiful to me) prefix stlsoft_
> >
> > :)
>
> A better solution would be to provide some knid of module/namespace concept for C imported stuff... so it would be C names that would be uglier and not the D ones...

Sorry, dude. I suspect we may be talking at cross-purposes. I was explaining the ugliness of the STLSoft static assert, precisely because it must take care of the CPP. I don't want anything like that in D. There's no need.

(Maybe we're in violent agreement. Dunno. :)

Matthew

Ok, everyone. I'm getting confused, and I suspect I'm not alone.

All I want is something that is analogous to assert(), except that it is
evaluated at compile-time, and called static_assert() (or, if we must,
ct_assert(), though I think that's ugly).

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.

Now some have argued that we should have a third category that checks invariants at compile-time if possible, otherwise at runtime. I do not think this is a good thing, but this is a different argument from whether we have a static assert. IMO the two things are entirely different, and should remain so. Even if we were to "allow" an implementation to do compile-time checks on runtime assertions, I think this would have unforeseen -ve consequences, though of course I cannot say what, since I have not foreseen them :(

So, I'd be keen to know everyone's desire for static assertions? Good thing/bad thing?

I'm not trying to stifle debate on whether a mixed-mode (compile-time if poss, falling back on runtime) assertion is a good thing, in fact I will be interested in such a debate. I'd just like to know what everyone thinks about a pure compile-time assertion, and (because I can't imagine anyone would not want one) what features we think it should have.

Matthew


"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bjb3fb$2l9s$1@digitaldaemon.com...
> Philippe Mori wrote:
>
> > A better solution would be to provide some knid of module/namespace concept for C imported stuff... so it would be C names that would be uglier and not the D ones...
>
> You haven't really read this thread, have you? :)
> It's technically impossible (and infeasible) to import
> stlsoft_static_assert into D, however hard you try! :)
> Nor is it possible to import any template library at all...
> It was about adding the language feature.
>
> > The best thing would be import with the possibility to qualify imported names (see also .h to D conversion thread).
>
> Why the hell? D forces modules on *everything*...
> Each source file is in a separate namespace.
>
> -eye
>

>
> > A better solution would be to provide some knid of module/namespace concept for C imported stuff... so it would be C names that would be uglier and not the D ones...
>
> You haven't really read this thread, have you? :)
> It's technically impossible (and infeasible) to import
> stlsoft_static_assert into D, however hard you try! :)
> Nor is it possible to import any template library at all...
> It was about adding the language feature.
>

Well, I might have not understand well from where stlsoft_static_assert come from... I was thinking that stlsoft_ prefix was added to avoid some conflicts with other definition of static_assert...

> > The best thing would be import with the possibility to qualify imported names (see also .h to D conversion thread).
>
> Why the hell? D forces modules on *everything*...
> Each source file is in a separate namespace.
>

Not for D stuff. It would be a pain but maybe if we uses
C stuff, we might like to make it appears as one module
to ensure it won't conflict with D.

So my suggestion was essentially to make name that
come from C uglier if necessary and ensure that D name
are friendly....

> Ok, everyone. I'm getting confused, and I suspect I'm not alone.
>
> All I want is something that is analogous to assert(), except that it is
> evaluated at compile-time, and called static_assert() (or, if we must,
> ct_assert(), though I think that's ugly).
>
> static_assert() would:
>   - not issue code under any circumstances. It's entirely compile-time

This is a good thing as some C++ solutions will generate extra code at least in debug version when the stuff doesn't get inlined.

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

By default, it should be an error and ideally we would have some control on the displayed message (being able to print constants or type...).

We would then decide one oof the following solution:

1) Uses some printf style message maybe with limited formatting.

        static_assert(sizeof a < sizeof b, "a is too big (a = %d, b = %d)",
sizeof a, sizeof b)

    that will output something like :

        a is too big (a = 34, b = 4)

2) The compiler would have an option to display "computed expression
automatically (we might have a verbose option)

        static_assert(sizeof a < sizeof b, "a is too big")

    that will output something like

        a is too big
        34 {sizeof a} < 3 {sizeof b}

3) Something between those 2 options:

        static_assert(sizeof a < sizeof b, "a is too big", sizeof a, sizeof
b)

       thew ouput would be

        a is too big
        sizeof a : 34
        sizeof b : 3


I think I prefer the third solution. The first argument is the condition,
the
second one is the message displayed to the user and remainding arguments
are optional expression to evaluate and display if the verification fails.

The message is also optional... A default message is displayed if none is provided.

>   - issue a rejection, plus appropriately distinct (i.e. from from
invariant
> invalidity) message if the code is run-time evaluable.
>

Yes, it would be an error if the condition cannot be evaluated at compile
time. The message would be somewhat different to the message when
the evaluation fails... We should indicated which part cannot be evaluated.

> Now some have argued that we should have a third category that checks invariants at compile-time if possible, otherwise at runtime. I do not
think
> this is a good thing, but this is a different argument from whether we
have
> a static assert. IMO the two things are entirely different, and should remain so. Even if we were to "allow" an implementation to do compile-time checks on runtime assertions, I think this would have unforeseen -ve consequences, though of course I cannot say what, since I have not
foreseen
> them :(
>

In fact, I'm not sure if a third type is necessary or if we should try to evaluate all normal assertion at compile time...

I do however think we need to be able to support an assertion that can be both at the same time.

Say that I have a function f in class A and B (where B derives from A)
and that f is not yet implemented in class B... I would like that the
compiler
issues an error when it is know at compile time that B.f() is called and
issues a run-time assertion if called at run-time...

IMO, it would be better to have a third category as it would allows us to have more controls on what happens at compile-time vs what happen at run time...

> So, I'd be keen to know everyone's desire for static assertions? Good thing/bad thing?
>

Static assertion are a good thing and being able to knows for sure that
an assertion is compile-time, run-time or both is usefull. We need at least
2 categories (compile-time and both run-time and compile-time).

Note that we may add a 4 category if it is desirable that run-time generate an error if they can always be evaluated at compile-time. That category would be either and won't be affected by changes that make something be constant or not at compile time. This could be the case if someone want to uses global constant to control check that are active.

const bool assertion_enabled = false;

assert(assertion_enabled && my_check());

Here it is possible to activate/desactivate a group of check using a constant...

Another possibility would be to have a modifier to indicate that a function is an assertion function...

I would also like the ability to display expression for failed run-time assertiion....

> I'm not trying to stifle debate on whether a mixed-mode (compile-time if poss, falling back on runtime) assertion is a good thing, in fact I will
be
> interested in such a debate. I'd just like to know what everyone thinks about a pure compile-time assertion, and (because I can't imagine anyone would not want one) what features we think it should have.
>
>

Pure compile-time is need and run-time is also required...

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bjbrk0$kua$2@digitaldaemon.com...
> Now some have argued that we should have a third category that checks invariants at compile-time if possible, otherwise at runtime. I do not
think
> this is a good thing, but this is a different argument from whether we
have
> a static assert. IMO the two things are entirely different, and should remain so. Even if we were to "allow" an implementation to do compile-time checks on runtime assertions, I think this would have unforeseen -ve consequences, though of course I cannot say what, since I have not
foreseen
> them :(

I can't foresee any problems either.  I want to know about assert failures as early as possible, at compile time is better than at runtime in all cases.

> So, I'd be keen to know everyone's desire for static assertions? Good thing/bad thing?

Good thing.

> I'm not trying to stifle debate on whether a mixed-mode (compile-time if poss, falling back on runtime) assertion is a good thing, in fact I will
be
> interested in such a debate. I'd just like to know what everyone thinks about a pure compile-time assertion, and (because I can't imagine anyone would not want one) what features we think it should have.

I think the compiler should have some way of doing compile-time asserts. I'd rather just have the mixed-mode assert, where the compiler attempts to evaluate the expression at compile time, and if triggered, gives a compiler error, and if it isn't fully evaluatable at compile time, generates runtime code.

This would be useful to keep people from instantiating template libraries with invalid parameters and such.  Stuff that the compiler wouldn't otherwise catch but which would be an obvious error to the template library writer.  We don't have parameter type constraints yet.  What if your integer template can only handle values > 0?

> Matthew

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.

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.

Sean

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bjcs0m$28bm$1@digitaldaemon.com...
> > Ok, everyone. I'm getting confused, and I suspect I'm not alone.
> >
> > All I want is something that is analogous to assert(), except that it is
> > evaluated at compile-time, and called static_assert() (or, if we must,
> > ct_assert(), though I think that's ugly).
> >
> > static_assert() would:
> >   - not issue code under any circumstances. It's entirely compile-time
>
> This is a good thing as some C++ solutions will generate extra code at least in debug version when the stuff doesn't get inlined.
>
> >   - 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.)
>
> By default, it should be an error and ideally we would have some control on the displayed message (being able to print constants or type...).
>
> We would then decide one oof the following solution:
>
> 1) Uses some printf style message maybe with limited formatting.
>
>         static_assert(sizeof a < sizeof b, "a is too big (a = %d, b =
%d)",
> sizeof a, sizeof b)
>
>     that will output something like :
>
>         a is too big (a = 34, b = 4)
>
> 2) The compiler would have an option to display "computed expression
> automatically (we might have a verbose option)
>
>         static_assert(sizeof a < sizeof b, "a is too big")
>
>     that will output something like
>
>         a is too big
>         34 {sizeof a} < 3 {sizeof b}
>
> 3) Something between those 2 options:
>
>         static_assert(sizeof a < sizeof b, "a is too big", sizeof a,
sizeof
> b)
>
>        thew ouput would be
>
>         a is too big
>         sizeof a : 34
>         sizeof b : 3
>
>
> I think I prefer the third solution. The first argument is the condition,
> the
> second one is the message displayed to the user and remainding arguments
> are optional expression to evaluate and display if the verification fails.
>
> The message is also optional... A default message is displayed if none is provided.
>
> >   - issue a rejection, plus appropriately distinct (i.e. from from
> invariant
> > invalidity) message if the code is run-time evaluable.
> >
>
> Yes, it would be an error if the condition cannot be evaluated at compile
> time. The message would be somewhat different to the message when
> the evaluation fails... We should indicated which part cannot be
evaluated.
>
> > Now some have argued that we should have a third category that checks invariants at compile-time if possible, otherwise at runtime. I do not
> think
> > this is a good thing, but this is a different argument from whether we
> have
> > a static assert. IMO the two things are entirely different, and should remain so. Even if we were to "allow" an implementation to do
compile-time
> > checks on runtime assertions, I think this would have unforeseen -ve consequences, though of course I cannot say what, since I have not
> foreseen
> > them :(
> >
>
> In fact, I'm not sure if a third type is necessary or if we should try to evaluate all normal assertion at compile time...
>
> I do however think we need to be able to support an assertion that can be both at the same time.
>
> Say that I have a function f in class A and B (where B derives from A)
> and that f is not yet implemented in class B... I would like that the
> compiler
> issues an error when it is know at compile time that B.f() is called and
> issues a run-time assertion if called at run-time...
>
> IMO, it would be better to have a third category as it would allows us to have more controls on what happens at compile-time vs what happen at run time...
>
> > So, I'd be keen to know everyone's desire for static assertions? Good thing/bad thing?
> >
>
> Static assertion are a good thing and being able to knows for sure that an assertion is compile-time, run-time or both is usefull. We need at
least
> 2 categories (compile-time and both run-time and compile-time).
>
> Note that we may add a 4 category if it is desirable that run-time generate an error if they can always be evaluated at compile-time. That category would be either and won't be affected by changes that make something be constant or not at compile time. This could be the case if someone want to uses global constant to control check that are active.
>
> const bool assertion_enabled = false;
>
> assert(assertion_enabled && my_check());
>
> Here it is possible to activate/desactivate a group of check using a constant...
>
> Another possibility would be to have a modifier to indicate that a function is an assertion function...
>
> I would also like the ability to display expression for failed run-time assertiion....
>
> > I'm not trying to stifle debate on whether a mixed-mode (compile-time if poss, falling back on runtime) assertion is a good thing, in fact I will
> be
> > interested in such a debate. I'd just like to know what everyone thinks about a pure compile-time assertion, and (because I can't imagine anyone would not want one) what features we think it should have.
> >
> >
>
> Pure compile-time is need and run-time is also required...
>
>

"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... :)

About "mixed-mode" assertions, well, if an expression is completely evaluable at compile time (an optimizing compiler should give it a try, no matter if it is inside an assert or not...) it will always either fail or pass, which makes the use of such an expression as an assertion at the least questionable; so I think a compile-time warning (if not an error) should be issued in _both_ cases.

Ric