Re: [boost] Deprecate BOOST_STATIC_ASSERT?

From: John Maddock (jz.maddock_at_[hidden])
Date: 2008-06-21 06:38:36

David Abrahams wrote:
> Yesterday someone on the user's list posted a message
> (http://article.gmane.org/gmane.comp.lib.boost.user/36884) about a
> "compilation error in the boost code:"
>
>  s-test.h:49:   instantiated from here
>  /usr/include/boost/archive/detail/oserializer.hpp:567: error: invalid
>  application of 'sizeof' to incomplete
>  type 'boost::STATIC_ASSERTION_FAILURE<false>'
>  make: *** [stest] Error 1
>
> and proceeded to try to analyze the BOOST_STATIC_ASSERT implementation
> to see what was wrong with it.  Granted, most people figure out what a
> static assertion is supposed to be, but still, the error message gave
> no
> clue about what might have gone wrong... no clue to the user, and no
> clue to anyone reading his posting, unless they were going to look up
> the line in the source file... oops, I take it back.  My copy of
> oserializer.hpp doesn't even have a line 567, and the posting doesn't
> indicate which version the user has.
>
> For several releases now we've had a suite of static assertion tools
> that give far superior error messages to what BOOST_STATIC_ASSERT can
> provide
> (http://www.boost.org/doc/libs/1_35_0/libs/mpl/doc/refmanual/asserts.html).
> I think <radical-idea>it's time to deprecate
> BOOST_STATIC_ASSERT</radical-idea> or at *least* put a prominent note
> in
> its documentation directing people at the BOOST_MPL_ASSERT macros.
>
> Thoughts?

I'm in two minds over this: yes we should direct people to the best that we
have.  However, once compilers start supporting a native static_assert we
can redirect BOOST_STATIC_ASSERT to that and get *much* better messages (of
course the MPL macros may do the same thing).

The other issue is with MPL's messages: sorry Dave, but the first time I saw
an MPL assertion failure, my immediate reaction was "what the heck is that?"
:-(

I've certainly no objection to updating the docs to refer to the MPL asserts
as well though.

What do others think?

John.