David Abrahams wrote:
Andrey Semashev wrote:
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).
Oh, I agree. Probably even if we _are_ speaking of static_assert in C++0x. The problem of course is that (generalizing wildly here):
1. users don't look at the code
True, at least they don't want to.
2. users can't even locate the line where the error occurred in a long instantiation backtrace
BOOST_MPL_ASSERT does no better here. It allows to put some hints on the problem source in the error message but nothing more. But even that makes little good since it can be difficult to find those hints in the backtrace. IMHO, most of the time users will eventually want to see the comment near the check anyway (and with experience I find it easier than decyphering rant of the compiler).
3. the part of the backtrace they paste into their problem reports doesn't contain the information you need to know what went wrong.
The point is that BOOST_MPL_ASSERT does a better job of highlighting the actual problem.
I think this point is oriented towards Boost maintainers. We should not forget that BOOST_STATIC_ASSERT is a part of public interface and users use it too. By deprecating it we effectively forbid to use it. I think if a Boost (or non-Boost) library maintainer wants he can use MPL macros to improve compiler-generated messages, he just needs to know that they exist. No need to bother users.
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
How do you manage to use BOOST_STATIC_ASSERT without compile-time constants?
With types and type traits. That makes BOOST_STATIC_ASSERT usage similar to BOOST_MPL_ASSERT, though.
and (c) it would introduce dependency on MPL where there was no such dependency.
That can be dealt with, if necessary, by factoring out that part of the library.
Maybe that should not be a part of MPL? After all, compiler diagnostics is out of scope of the library. I think, Boost.StaticAssert library would be a better place for such facilities.