Re: [boost] Deprecate BOOST_STATIC_ASSERT?

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-23 13:07:45

Andrey Semashev wrote:
> 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 makes one part of the message stand out better than the others.  You
don't think ****************** error-message:: ********************* is
more likely to get noticed and pasted into a problem report?

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

Seriously?  You don't find those asterixes make things stand out
sufficiently?

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

You said yourself that users don't want to look at the code.  The
comment is in the code.

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

Not exactly, although your point is taken.  I am not arguing that it
should be forbidden.

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

Which users?  How is that group different from the group of Boost (or
non-Boost) library maintainers?

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

Err, BOOST_STATIC_ASSERT((expression)) requires that expression is a
compile-time constant, whether it involves types and traits or not.
Perhaps you meant something else, such as...

> That makes BOOST_STATIC_ASSERT usage similar
> to BOOST_MPL_ASSERT, though.

"...complicate condition expressions with types and type traits."

Well, if you're using types and type traits anyway, the tendency of
BOOST_MPL_ASSERT is to make your condition expressions much *simpler*
than they would be with BOOST_STATIC_ASSERT.  And if you're writing an
expression that is simpler *without* types and type traits,
BOOST_MPL_ASSERT_RELATION is often a better bet anyway.

>>> 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? 

I don't know whether it should or shouldn't, but separating it from MPL
was what "factoring out that part of the library" was meant to suggest.

> After all, compiler diagnostics
> is out of scope of the library. I think, Boost.StaticAssert library
> would be a better place for such facilities.

That approach would be okay with me.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com