Proposed resolution:

Add the following type traits to p3 [ratio]

// ratio arithmetic
template <class R1, class R2> struct ratio_add;
template <class R1, class R2> struct ratio_subtract;
template <class R1, class R2> struct ratio_multiply;
template <class R1, class R2> struct ratio_divide;
template <class R1, class ... RList> struct ratio_sum;
template <class R1, class ... RList> struct ratio_product;

after [ratio.arithmetic] p1: add

template <class R1, class ... RList> struct ratio_sum; // declared, never defined

template <class R1> struct ratio_sum<R1> : R1 {};

Requires: R1 is a specialization of class template ratio

template <class R1, class R2, class ... RList> 
 struct ratio_sum<R1, R2, RList...>
   : ratio_add< R1, ratio_sum<R2, RList...>> {
};

Requires: R1 and each element in parmater pack RList is a specialization of class template ratio

after [ratio.arithmetic] p3: add

template <class R1, class ... RList> struct ratio_product; // declared, never defined

template <class R1> struct ratio_product<R1> : R1 {};

Requires: R1 is a specialization of class template ratio

template <class R1, class R2, class ... RList> 
 struct ratio_sum<R1, R2, RList...>
   : ratio_add< R1, ratio_product<R2, RList...>> {
};

Requires: R1 and each element in parmater pack RList is a specialization of class template ratio

Proposed resolution:

Add the following type traits to p3 [ratio]

// ratio arithmetic
template <class R1, class R2> struct ratio_add;
template <class R1, class R2> struct ratio_subtract;
template <class R1, class R2> struct ratio_multiply;
template <class R1, class R2> struct ratio_divide;
template <class R1, class ... RList> struct ratio_sum;
template <class R1, class ... RList> struct ratio_product;

after [ratio.arithmetic] p1: add

template <class R1, class ... RList> struct ratio_sum; // declared, never defined

template <class R1> struct ratio_sum<R1> : R1 {};

Requires: R1 is a specialization of class template ratio

template <class R1, class R2, class ... RList> 
 struct ratio_sum<R1, R2, RList...>
   : ratio_add< R1, ratio_sum<R2, RList...>> {
};

Requires: R1 and each element in parmater pack RList is a specialization of class template ratio

after [ratio.arithmetic] p3: add

template <class R1, class ... RList> struct ratio_product; // declared, never defined

template <class R1> struct ratio_product<R1> : R1 {};

Requires: R1 is a specialization of class template ratio

template <class R1, class R2, class ... RList> 
 struct ratio_sum<R1, R2, RList...>
   : ratio_add< R1, ratio_product<R2, RList...>> {
};

Requires: R1 and each element in parmater pack RList is a specialization of class template ratio

Rationale:

Does not have sufficient support at this time. May wish to reconsider for a future standard.

[ 2009-10-30 Alisdair adds: ]

The consensus of the group when we reviewed this in Santa Cruz was that 921 would proceed to Ready as planned, and the multi-paramater add/multiply templates should be renamed as ratio_sum and ratio_product to avoid the problem mixing template aliases with partial specializations.

It was also suggested to close this issue as NAD Future as it does not correspond directly to any NB comment. NBs are free to submit a specific comment (and re-open) in CD2 though.

Walter Brown also had concerns on better directing the order of evaluation to avoid overflows if we do proceed for 0x rather than TR1, so wording may not be complete yet.

Alisdair updates wording. 2009-10-30 Howard:

Moved to Tentatively NAD Future after 5 positive votes on c++std-lib.

LEWG Kona 2017

PR for ratio_product is wrong, uses ratio_add instead of ratio_multiply. Recommend NAD: Doesn't meet the bar for standardization: hasn't been requested again in 7 years, easy to implement yourself.

Both add and multiply could sensibly be called with more than two arguments. The variadic template facility makes such declarations simple, and is likely to be frequently wrapped by end users if we do not supply the variant ourselves.

We deliberately ignore divide at this point as it is not transitive. Likewise, subtract places special meaning on the first argument so I do not suggest extending that immediately. Both could be supported with analogous wording to that for add/multiply below.

Note that the proposed resolution is potentially incompatible with that proposed for 921, although the addition of the typedef to ratio would be equally useful.