Proposed resolution:

Change [time.traits.is_fp]/1:

1 The duration template uses the treat_as_floating_point trait to help determine if a duration object can be converted to another duration with a different tick period. If treat_as_floating_point<Rep>::value is true, then Rep is a floating-point type and implicit conversions are allowed among durations. Otherwise, the implicit convertibility depends on the tick periods of the durations. If Rep is a class type which emulates a floating-point type, the author of Rep can specialize treat_as_floating_point so that duration will treat this Rep as if it were a floating-point type. Otherwise Rep is assumed to be an integral type or a class emulating an integral type. [Note: The intention of this trait is to indicate whether a given class behaves like a floating point type, and thus allows division of one value by another with acceptable loss of precision. If treat_as_floating_point<Rep>::value is false, Rep will be treated as if it behaved like an integral type for the purpose of these conversions. — end note]

[ Adopted at 2010-11 Batavia ]

[ 2010 Rapperswil: ]

Move to Ready.

[ 2010-02-11 Stefanus provided wording. ]

[ 2009-10 Santa Cruz: ]

Stefanus to provide wording to turn this into a note.

[ 2009-08-01 Howard adds: ]

I have surveyed all clauses of [time.traits.duration_values], [time.traits.specializations] and [time.duration]. I can not find any clause which involves the use of a duration::rep type where the requirements on the rep type are not clearly spelled out. These requirements were carefully crafted to allow any arithmetic type, or any user-defined type emulating an arithmetic type.

Indeed, treat_as_floating_point becomes completely superfluous if duration::rep can never be a class type.

There will be some Rep types which will not meet the requirements of every duration operation. This is no different than the fact that vector<T> can easily be used for types T which are not DefaultConstructible, even though some members of vector<T> require T to be DefaultConstructible. This is why the requirements on Rep are specified for each operation individually.

In [time.traits.is_fp] p1:

template <class Rep> struct treat_as_floating_point
  : is_floating_point<Rep> { };

The duration template uses the treat_as_floating_point trait to help determine if a duration object can be converted to another duration with a different tick period. If treat_as_floating_point<Rep>::value is true, then Rep is a floating-point type and implicit conversions are allowed among durations. Otherwise, the implicit convertibility depends on the tick periods of the durations. If Rep is a class type which emulates a floating-point type, the author of Rep can specialize treat_as_floating_point so that duration will treat this Rep as if it were a floating-point type. Otherwise Rep is assumed to be an integral type or a class emulating an integral type.

The phrases "a class type which emulates a floating-point type" and "a class emulating an integral type" are clarifying phrases which refer to the summation of all the requirements on the Rep type specified in detail elsewhere (and should not be repeated here).

This specification has been implemented, now multiple times, and the experience has been favorable. The current specification clearly specifies the requirements at each point of use (though I'd be happy to fix any place I may have missed, but none has been pointed out).

I am amenable to improved wording of this paragraph (and any others), but do not have any suggestions for improved wording at this time. I am strongly opposed to changes which would significantly alter the semantics of the specification under [time] without firmly grounded and documented rationale, example implementation, testing, and user experience which relates a positive experience.

I recommend NAD unless someone wants to produce some clarifying wording.

[ Batavia (2009-05): ]

As with issue 953, we recommend this issue be addressed in the context of providing concepts for the entire thread header.

We look forward to proposed wording.

Move to Open.

[ 2009-05-10 Howard adds: ]

IntegralLike.

Related to 953.

[time.traits.is_fp] says that the type Rep "is assumed to be ... a class emulating an integral type." What are the requirements for such a type?