Andy Little wrote:
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?
1. to reduce number of instantiations in template code. For example: enum bits { bit1 = 1, bit2 = 2 }; lexical_cast<double>(bit1); lexical_cast<double>(bit1|bit2); produces 2 instantiantions of lexical_cast and 2 instantiantions of detail::lexical_stream. In general, this number is proportional to a number of enums used. If lexical_cast were to apply integral_promotion, this could reduce number of instantiantions of lexical_stream to one. 2. to find a type that can hold all values of enum type. This technique can be used in langbinding to make sure that all C++ enum values are mapped without truncation. 3. to use in other metafunctions like arithmetic_convertion_traits and to provide a solution for (_1 | _2)(bit1, bit2) lambda expression.
IMO All this has recently been superceded by Boost.Typeof.
Only native mode of Boost.Typeof can compete with hand-made integral_promotion or arithmetic_convertion_traits. Emulation is too complex and require registration of every enum type. Even in native mode you would need more then typeof(+T()) simply because this expression is not valid for some types. You should write is_subject_to_integral_promotion<T> metafunction and use eval_if.
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. I knew this :) but I decided that writing eval_if< is_subject_to_integral_promotion<T>, ... > is not worth it. Existing behavior is better in all use-cases listed above. -- Alexander Nasonov