Consider wait_traits vs extending Clock requirements vs nothing

[chriskohlhoff]

[ja11sop]

Just a short note to point out that I looked at scheduling as being another use-case for this: that is error correcting and min/max resolution etc.

[chriskohlhoff]

Pre-Lenexa Summary

[timer.reqmts.waittraits]

The wait traits is a customisation point that may be used for several different things:

• Allowing the use of timers based on non-real-time clocks. E.g. to use simulated times. See http://blog.think-async.com/2007/08/time-travel.html for example.
• Determining how quickly wallclock-based timers respond to system time changes.
• Correcting for errors, rounding, putting timers into buckets.
• Addressing the std::chrono duration overflow issue. That is, people may wish to schedule timers at Clock::max() (meaning never reached) or Clock::min() (meaning always in the past). However these can trigger duration overflow when compared to Clock::now() unless extra care is taken.

The options are:

• Keep the wait traits as is.
• Change to use an optional refinement of the existing Clock requirements.
• Remove wait traits.

I am not in favour of any change in this area.

[ja11sop]

I have to agree with this summary - wait traits supports a common use case in a clean, extensible way. If you don't need it you don't have to care about it.