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?
As a user and a library writer I would ask to keep BOOST_STATIC_ASSERT as it is without deprecation. I'm using this macro on a regular basis and found no problems with it. I usually put a comment near the macro that explains what the check does and I'm very sure the comment will be far more informative than any compiler-generated error message (unless we are speaking of static_assert in C++0x). I wouldn't like to move to BOOST_MPL_ASSERT since (a) it would require to change my code (b) it would complicate condition expressions with compile-time constants and (c) it would introduce dependency on MPL where there was no such dependency. However, I think pointers to MPL docs near BOOST_STATIC_ASSERT description is a good idea.