[boost] [config][mpl][type_traits][integer] BOOST_STATIC_CONSTANT should use constexpr

Subject: [boost] [config][mpl][type_traits][integer] BOOST_STATIC_CONSTANT should use constexpr
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-20 04:03:39

Hi,

BOOST_STATIC_CONSTANT could be improved to make use of constexpr. This 
is needed for instance to make integral_constant compliant with C++11.

The patch consists in changing const by BOOST_CONSTEXPR_OR_CONST in 
boost/config/suffix.hpp

// BOOST_STATIC_CONSTANT workaround 
--------------------------------------- //
// On compilers which don't allow in-class initialization of static integral
// constant members, we must use enums as a workaround if we want the 
constants
// to be available at compile-time. This macro gives us a convenient way to
// declare such constants.

#  ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION
#       define BOOST_STATIC_CONSTANT(type, assignment) enum { assignment }
#  else
#     define BOOST_STATIC_CONSTANT(type, assignment) static 
*BOOST_CONSTEXPR_OR_CONST* type assignment
#  endif

and in each out of line static constant definition as in

template <int b1, int b2> bool *BOOST_CONSTEXPR_OR_CONST* 
ice_eq<b1,b2>::value;

The main problem is that this is a *breaking change*: the list of 
concerned libraries is quite big (mpl, type_traits/integer_traits, ...) 
and users of BOOST_STATIC_CONSTANT would need to make this modification 
also.

An alternative is to define a BOOST_STATIC_CONSTANT_11 that includes 
this modification and update the Boost libraries that could  make use of 
the new macro without introducing a breaking change.

Library providing a template class containing a field with such a change 
that can be specialized by the user would need to either announce a 
breaking change or just don't use the new macro.

While this mean more changes the backward compatibility can be mastered.

What do you think, it is worth try to fixing this?

Best,
Vicente