Re: [boost] [mpl] Integral Constant is over specified

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-07-26 00:31:51

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