"Peter Dimov" wrote
Andy Little wrote:
What is the problem with the result of plus<int_<A>,int_<B>> being int_<A+B> ?
How does the specification of mpl::plus look like in your proposed model?
Firstly the signature : namespace boost{ namespace mpl{ template <typename Lhs, typename Rhs> struct plus; }} IOW the function doesnt have more than 2 parameters Rationale: The extra parameters are * unexpected * a nuisance when specialising for a UDT. * irrelevant in many uses eg with mpl::transform. * lengthen error messages. * more likely to overflow. I realise that would break existing code but I bring it up as a discussion point if mpl was ever the subject of standardisation for example. Secondly the type of the result As a workaround to the status quo I would suggest that where the first two parameters are of the same integral_constant template type and the rest arent specified by the user ( ie left as the default mpl::na), the template type of the result should be the same as the template type of the integral constant parameters. note: If the first modification was unacceptable then the rule could of course be extended to further numbers of integral_constant parameters, otherwise if the first modification was acceptable then the following code is still valid. Example typedef mpl::plus<mpl::int_<1>,mpl::int_<2> >::type int_two; assert((boost::is_same<int_two,mpl::int_<3> >::value)); typedef mpl::plus< mpl::integral_c<long,1>,mpl::integral_c<long,-1> >::type long_c_two; assert((boost::is_same< long_c_two,mpl::integral_c<long,0> >::value)); As a refinement promotion rules would add certainty in further cases of integral_constant combinations. The current spec gives an example indicating something similar with regard to value_type but AFAIK no wording. The same rules would apply to mpl::minus,mpl::times, mpl::divides, and logical operators etc As far as I know that is the extent of the modifications to the current spec. regards Andy Little