Boost public interface macro names

From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-07 11:18:45

In the past we have used a number of macro names, always prefixed by 
BOOST_.

Examples are multiple inclusion guards like BOOST_CONFIG_HPP or 
configuration artifacts like BOOST_NO_MEMBER_TEMPLATES.

These names are implementation details, and not part of the public 
interface.  Thus if they are a bit on the ugly side that may be an 
advantage because it both reduces the chance of name clashes and warns 
users to avoid these names.

Boost is about to review John Maddock's static assert, which has a macro as 
part of its public interface.  Beyond that, I'm about to propose some test 
tools, which will have two macros as part of their public interface.  Thus 
boost users and developers may be writing code like:

    BOOST_STATIC_ASSERT( a == b );
    BOOST_TEST_ASSERT( c == d );
    BOOST_TEST_VERIFY( e == f );

Let's assume those names do a good job of denoting the semantics, and talk 
about their lexical aspect.

My question then is, "What should be the form of boost public interface 
macro names?"

My worry is that the all uppercase, prefixed by BOOST_ rule produces names 
ugly enough that programmers will shy away from using them.  Is there 
another scheme that is less ugly, but still unlikely to produce name 
conflicts?

For example, would this be better:

    static_assert_macro( a == b );
    test_assert_macro( c == d );
    test_verify_macro( e == f );

or this:

    static_assert_macro_( a == b );
    test_assert_macro_( c == d );
    test_verify_macro_( e == f );

Maybe I'm the only one that worries about public interface macro names, but 
I'd like to someone else can come up with a better scheme before we commit 
ourselves to names that are likely to be around for many years.

--Beman