Andy Little writes:
IMO the Integral Constant Concept is over specified in the mpl docs. What is the rationale behind the next<..> and prior <..> requirements?
The corresponding operations are handy and available for every integral type?
These seem to have little to do with an Integral Constant.
IMO that's equivalent to saying that operations of increment and decrement have little to do with a concept of an integer number.
Maybe they should rather be another Concept , such as Iterable?
They _could be_ factored out in a separate concept, but that doesn't automatically means denying users the guarantee of having convenient access to the basic operations like increment/decrement.
Where N is a model of Iterable:
next<N>::type prior<N>::type
Currently for example, mpl::bool_ is stated to be a model of Integral Constant, but it fails to meet the curently stated requirments, nor can it ever AFAICS.
Surely this could work and would make sense, no? BOOST_MPL_ASSERT(( is_same< next<false_>::type, true_ > )); BOOST_MPL_ASSERT(( is_same< prior<true_>::type, false_ > ));
Further the requirements currently include a member ::value_type. According to the TMP book, this is a classic example of a traits blob. (section 2.2).
In a way.
Surely access should be specified using value_type<C>::type?
It could be (ignoring for the moment the fact that the 'value_type' name is already taken), but it has nothing to do with the presence of the requirement, in whatever form, in the concept.
IOW maybe a ValueType Concept.
Theoretically, we could factor out every single requirement in its own concept, but that doesn't necessarily going to improve the quality of the resulting concept language.
Finally the runtime evaluation requirement could be removed and a refinement of ValueType such as RunTime Evaluable be stated in terms such as:
Where T is a type modelling Runtime Evaluable
value_type<T>::type = t();
Again, I don't see any value in denying users of the concept access to the functionality that is by definition available for every possible model of the concept.
For a type N The current Integral Constant spec would then, in those places where these requirements are required:
N is a model of Iterable, Integral Constant and Runtime Evaluable.
I don't see how this is an improvement, given that IMO every integral constant is by definition Iterable and Runtime Evaluable.
This would allow me to meet the new Integral Constant requirements without unneccesary baggage.
May be if you start with describing what you are trying to achieve and how the Integral Constant's requirements stand in your way, we'd have better chances of figuring out the best way to resolve these issues. -- Aleksey Gurtovoy MetaCommunications Engineering