[ 2009-09-05 Daniel adds: ]

I think that the suggested resolution is incomplete and may have some possible unwanted side-effects. To understand why, note that integral_constant is completely specified by code in [meta.help]. While this is usually considered as a good thing, let me give a possible user-defined specialization that would break given the suggested changes:

enum NodeColor { Red, Black };

std::integral_constant<NodeColor, Red> red;

The reason why that breaks is due to the fact that current core language rules does only allow integral types as enum-bases, see [dcl.enum]/2.

So, I think that we cannot leave the implementation the freedom to decide which way they would like to provide the implementation, because that is easily user-visible (I don't speak of addresses, but of instantiation errors), therefore if applied, this should be either specified or wording must be added that gives a note about this freedom of implementation.

Another possible disadvantage seems to me that user-expectations are easy to disappoint if they see a failure of the test

assert(typeid(std::integral_constant<int, 0>::value) == typeid(int));

or of

static_assert(std::is_same<decltype(std::integral_constant<int, 0>::value), const int>::value, "Bad library");