Potential project: Resolving boost::chrono conflicts with std::chrono

From: Mike (mike.dev_at_[hidden])
Date: 2019-08-12 08:11:48

For what it is worth, I'd prefer the solution proposed by
Alexander to effectively make the boost::chrono types
aliases for the equivalent std::chrono types and let
boost::chrono provide additional functionality on top of
those (such as I/O support, and additional clocks).

At the end of the day, it means less code to maintain,
document, test and distribute and the least amount of
interoperability problems.
Above all else, types like duration and time_point are
interface types. If one library gives me a duration and
I want to pass that to another library, I don't want to have
to worry about converting types or worst of all mixing
up scales (micro vs milli).

**Solving this interoperability problem is exactly what standards are for!**

Hence it should be left to the standard library to
provide them wherever possible.

So whatever else your opinion on the proper scope of
the standard library and the committee's responsibility is,
please don't try to overshoot your target. In particular
not where already existing types are concerned.

On a practical note: As such a change would be breaking
in more than one way (c++11, ADL-effects and multiple
function overloads that now resolve to the same signature
come to mind), this should be announced 1-2 releases in
advance -- which of course requires that someone with the
necessary authority actually makes a decision.

An intermediate step might be to e.g. let boost duration
inherit from std duration and add a implicit conversion
constructor. That way ADL should continue to work as
expected and previously distinct types would remain distinct
types. However it would still require c++11 and there might
be more subtle ways in which this breaks existing code.

Best

Mike