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

From: David Abrahams (dave_at_[hidden])
Date: 2006-08-05 12:42:35

"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:
>>>
>>> <...>
>>>
>>>> There is no absolute notion of the minimum set of requirements. For
>>>> one, the abstract minimum is of course having no requirements at all,
>>>> and obviously that would hardly give us a useful set of concepts.
>>>
>>> AnyType would be a useful Concept, similar to the universal set:
>>>
>>> Where A and B are models of AnyType
>>
>> That's meaningless.  Just leave out the "where."
>
> What's meaningless? the AnyType Concept or just the where?
>
>>> boost::is_same<A,B>
>>>
>>> Another use of AnyType would be to check that you have covered all use cases,
>>> when using enable_if for example.
>>> I don't know what the notation would be but for example
>>
>> Well, your example is too vague for me to understand.  Maybe if you
>> could provide some notation...
>
> I think even Anytype has some requirements. The only two I can think of are:
>
> typeid(AnyType)

Well, c'mon.  That's like saying AnyName "can be written down."

    typedef X y;

is also required where X is any type.  We don't need a new Concept for
that, because the C++ standard gives us "type."

> AnyType*

Not unless you want to rule out reference types.

> An aspiration
> AnyType  f();

Not unless you want to rule out array and function types.

>>> Obviously things can become much more complicated than this in
>>> practise, so its a useful general Concept, but maybe not inside mpl.
>>
>> Nothing you've written here leads me to conclude that it's useful.
>> Please show a real example (or just retract that claim; I doubt it's
>> central).
>
> What claim? That an AnyType Concept may not be useful in MPL?

No, that "AnyType would be a useful Concept."

> In general though an AnyType Concept would be a useful statement
> that there are no restrictions on the types allowed. It expresses
> the current situation regarding template parameters as a
> Concept. Its the most fundamental Concept of type and already exists
> in every template type parameter. 

Yeah, it's called "type."

> In fact it is currently the only
> Concept we have.

?? We've defined several type concepts in MPL, such as "nullary
Metafunction."

>>>> A meaningful minimum can only be derived from the relevant use
>>>> cases, and it's pointless to discuss one without having those on
>>>> the table.
>>>
>>> The minimal use of a StaticConstant is to return its value
>>
>> No, that's called CopyConstructible.
>
> At compile time?

You'd better be more precise in your language.  You can't literally
"return a value" at compile time.

>>> Where C is a model of StaticConstant
>>> get_value<C>::value
>>>
>>> A check on whether a type is a model of StaticConstant would also be useful:
>>>
>>> where C is a model of StaticConstant.
>>>
>>> is_constant<C>::value is true
>>
>> That's certainly not in the minimal set of requirements, since a
>> proven useful set (the one in MPL) doesn't include it.
>
> Its roughly equivalent to the member ::tag requirement, currently at
> least, required by mpl::equal_to when acting on models of
> mpl::IntegralConstant

Not at all.  It's one thing to require X::value or Y::tag, and quite
another to require is_constant<C>::value.

>>>>> 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.  

> 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.

> IOW if remove the next prior requirements, that is less
> specification, not more.

If we just do that, sure, but you're advocating the replacement of
specification for the simple next/prior requirements with that of all
the math, comparison, and logic operations!

>>>>> It should also be stated that these constants arent perfect models
>>>>> of integers, what happens in the case of math on constants of
>>>>> different value_types , whether a given math operation is possible (
>>>>> without overflow) and so on.
>>>>
>>>> Stated where?
>>>
>>> In general, wherever it is possible that a mistake and particularly
>>> a silent one can occur.
>>
>> Technically that's right, but I don't think it's a serious omission
>> when taken against a background of short,int,long,... all of which
>> have the same problem.
>
> So what? The compiler cant warn about it at runtime. 

I don't understand your point.

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