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

From: David Abrahams (dave_at_[hidden])
Date: 2006-07-28 10:16:13

"Andy Little" <andy_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:umzaulykv.fsf_at_boost-consulting.com...
>> "Andy Little" <andy_at_[hidden]> writes:
>>
>>> A bool_ is stated to be a model of Integral Constant, but it patently doesnt
>>> and
>>> can never meet the next / prior requirements.
>>
>> Well, that's not strictly true.  false_ and true_ can meet the
>> next/prior requirements just as well as int_<INT_MIN> and
>> int_<INT_MAX> can.
>
> Which is that they cant, so the statement is strictly true, INT_MIN and INT_MAX
> arent models of Integral Constant either, similar for unsigned types.

Yes, but then if int_<INT_MIN> is not a model, then by induction,
nothing is... beceause prev<int_<INT_MIN+1> >::type can't yield an
integral constant, and so on.

You can't claim that's because next/prev requiremens don't belong in
Integral Constant; we'd have the same problem with an "iterable"
concept.  We just need a better way to specify what happens at the
endpoints of the range.

And, I should add, calling Integral Constant a "traits blob" is a
serious stretch.  Integral Constant is a type concept that includes
"self-returning metafunction" mostly for convenience reasons.  That
is, the primary role of Integral Constant is not as a metafunction.

>> Any bounded type has the same problem; maybe we need to be more
>> precise about what happens at the endpoints of the range.
>
> I have found it essential for maths on a compile time rational, but
> its more critical there.
>
> As regards bool_ , the debate is interesting for theoreticians but
> for practical programmers, it should be a separate Concept .. 

You have said so many times but I have not seen any convincing
evidence that the existing concept definition is problematic other
than violating your personal sense of how things should be.

> simple and many of the type_traits functions should use that, which
> would remove the need for the true_or_false_type mullarkey.

I don't know what you're referring to.

> Also I suspect that the change from boost::is_same to std::is_same is going to
> break a lot of code, unless the mpl tag requiremnet is lifted ;-)

Ditto.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com