
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:umzaulykv.fsf@boost-consulting.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> 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