Re: [boost] Deprecate BOOST_STATIC_ASSERT?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-06-23 04:43:34

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.