Re: [boost] [review] promotion traits

From: Andy Little (andy_at_[hidden])
Date: 2006-04-01 19:42:30

"Alexander Nasonov" wrote
> Andy Little wrote:
>> Hi,
>>
>> I'm interested to know in what situations the promotion_traits libarary is
>> meant
>> to be used? I looked at the standard and I see that it seems to follow that,
>> but in practise the only similar situation of needing to know promotion rules
>> in
>> my own code was in choosing the type that the input types are to be converted
>> to
>> in some operation.
>
> Are you talking about _usual arithmetic conversions_?

I am talking about usefulness. In what practical situation is promotion_traits
likely to be used? Put it another way. What is the rationale for
promotion_traits?

> I like fine granular model. Since usual arithmetic conversions depend on
> integral promotion, it's logical to implement integral_promotion fisrt.
>
> BTW, LibrariesUnderConstruction has a reference to
> types_promotion_traits developed by Aleksey Gurtovoy.
> http://tinyurl.com/4kvla
> Is arithmetic_conversions_traits<> defined there what you need?

IMO All this has recently been superceded by Boost.Typeof.

>> I am surprised to see that input parameters unrelated to promotion are
>> allowed
>> to pass unchanged to the output.The example given is e.g
>>
>> Expression   ---> Result
>> floating_point_promotion<int const>::type   --->  int const
>>
>> I would expect, rather, to have a compilation failure in case of an invalid
>> parameter?
>
> I prefer promote-if-possible because it follows a semantic in the
> standard. For example, integral promotions can be applied when passing
> an argument to printf-like function. If integral promotions can't be
> applied to the argument, nothing happens.
>
> If you want to check whether promotion has an effect you can write
> is_same< T, promote<T>::type >::value.

It might help to show useage examples to decide the behaviour, but is it not
generally better to constrain a functions input to only those types for which
its functionality is meaningful?  If you want to widen the behaviour to accept
other types you can use mpl::eval_if for example.

regards
Andy Little