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

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-05 17:28:00

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uy7u32kxw.fsf_at_boost-consulting.com...
>> "Andy Little" <andy_at_[hidden]> writes:
>>
>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>> news:upsfhdfsd.fsf_at_boost-consulting.com...
>>>> "Andy Little" <andy_at_[hidden]> writes:
>>>>
>>>>> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
>>>>> news:m1k65tgzvi.fsf_at_meta-comm.com...
>>>>>> Andy Little writes:
>>>>>>
>>>>>>> In my use of integral constants, comparison for equality is the most
>>>>>>> used operation, followed by arithmetic.  I have never used the next
>>>>>>> ,prior functions. To me math ,comparison and logic operations are
>>>>>>> more likely candidates for Integral Constant Requirements.
>>>>>>
>>>>>> IMO they are too heavy-weight. I understand your desire to have a
>>>>>> concept encompassing these, but so far I don't see a compelling reason
>>>>>> why Integral Constant should be such a concept (and I find it somewhat
>>>>>> amusing that the title of this thread is "Integral Constant is over
>>>>>> specified" :).
>>>>
>>>> Aleksey's point here is that you are now advocating *more*
>>>> specification, which contradicts your subject line.
>>>
>>> Nope.
>>
>> Yep.
>
> Nope.  I am still advocating removing the next prior requirements, hence the
> title of the thread.

This is getting silly.  Are you, or are you not, advocating adding a
bunch of other requirements (math ,comparison and logic operations) to
the concept as well?

>>> Having next prior as requirements but not the usual operations on
>>> integers strikes me as odd.
>>
>> Yes, but that's not necessarily a good criterion for determining what
>> should be a concept.
>
> mpl::bool_ is stated to be a model of mpl::IntegralConstant, but
> exercising the requirements on it results in a failure to
> compile. Maybe the mismatch is acceptable to you, but I don't find
> it satisfactory.

It isn't satisfactory.  Look, we've been through this before; there
are lots of ways to deal with that problem.  Clearly the requirements
need a small adjustment to handle boundary cases anyway, because
exercising the requirements on int_<INT_MAX> results in undefined
behavior, which by induction means int_<X> is not an IntegralConstant
either.  Maybe bool_<true> needs next and bool_<false> needs prior
also.  

Until

  bool x = false;
  bool y = x + bool(1);

becomes illegal I'm not going to agree that next/prior is a defect in
IntegralConstant, and if it did become illegal I might just say we
need a new concept for bool.  If you want to say IntegralConstant
could be more intuitively (or even better) defined, great.  But your
approach is to assert that next/prior are definitively wrong is just
off-putting, because I know it's not as black-and-white as you seem to
assert.

If you have run into an actual problem, please describe it and how it
has come up in your work, and we can try to look for an appropriate
solution.  Changing concept requirements is a serious documentation-
and code-breaking change, and I wouldn't do it just because the
concept seems odd to you.

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