So where are we at with this? Have we reached to any conclusion yet?
As was previously mentioned in this thread, you should not expect the ML to come to any decision as it is ultimately the responsibility of the library maintainer to decide which way to go. I'm not sure of the ML has come to any decision on anything over the last couple years anyway (except for accepting/rejecting new libraries).
It’s hard to say. The C++/English ratio is awfully low. :-)
FWIW: I toyed a bit with different possible approaches: ##### # (I) I made a version where I replaced the definition of boost::ratio and boost::chrono types and functions with their std equivalents (e.g. using std::chrono::duration) where possible. This worked like a charm, with two exceptions: 1) If BOOST_RATIO_EXTENSIONS is defined, boost::ratio provides integration hooks into the mpl, which obviously are not provided by the std types. I didn't check if there was any way to do the same for std::ratio. 2) As mentioned before, boost::chrono provides io operators for duration and time point types. unless there is a using namespace boost::chrono, those are expected to be found via ADL and of course that doesn't work anymore. My quick fix, that allowed me to run all of the chrono and thread unit tests virtually unaltered was to: a) put the operators into their own inline namespace below boost::chrono b) And put a using namespace "boost::chrono::io_ops" into the global scope of the header Of course the latter would be completely unacceptable for a real implementation. In reality, the code that actually uses the streaming operators would have to do this. ##### # (II) I also looked a bit into the approach of inheriting the boost chrono types from std::chrono types and letting the boost::chrono functions wrap the native ones. It seems that in practice this would require far too much code chrun and potentially problematic effects on overload resolution to be justified by the gains. I see two realistic ways forward to solve the interoperability problem: a) 1) Replacie std::boost with std::chrono. This will be a breaking change even for projects that are using c++11+. 2) Mid to long term, dependencies on boost::chrono could probably be removed from most boost libraries that don't need the extended functionalities. In practice this would require a period, where both versions coexist. (Add a off-by-default config option that makes the boost types aliases for the std types, next release turn the option on by default and give a deprecation warning for the old one and finally remove the old version). On the up side it is will minimize any interoperability problems and will reduce the amount of code to test, maintain and compile (in my tests on a windows machine, compiling and running the boost chrono unit tests actually took less time with the changes). It is also best option for projects that just start to use related Boost libraries. b) 1) Provide some free functions like "to_boost_duation/ to_std_duration" in Boost.Chrono that the users can use when required and 2) add std::chrono::overloads to other boost libraries like Boost.Thread. This is (probably) a non-breaking change but 2) requires a lot more work across other parts of boost and I doubt it will actually happen at all. Also, we are probably forever stuck with a competing set of vocabulary types for chrono. I'd be willing to help with both approaches (although apparently anonymous contributions are problematic due to copyright). Personally, I'd prefer if boost would focus on being an easy to use extension to the standard library not yet another a competing implementation like EASTL. As I said before: The whole purpose of a standard is to allow products of different vendors to easily interoperate. Establishing a competing de-facto standard instead of building on top of the existing standard makes things harder - not easier for the ECO system. Best Mike