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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-08-12 08:24:01

Am 09.08.19 um 20:27 schrieb Edward Diener via Boost:
> If there is additional functionality in boost::chrono that is not in 
> std::chrono it probably can not rely on std::chrono to provide it. 
> Furthermore if there is additional functionality in std::chrono that 
> is not in boost::chrono your technique will expose it to users of 
> boost::chrono, and they would need to be told about it in the docs.
The point is: With the proposed change users can just pass any 
std::chrono type into boost::chrono and it will work (because they are 
the same). If the functionality called is the same as std::chrono, then 
that will be used. Otherwise the function from boost::chrono will be 
used. But all the *types* (classes) will be std::chrono.
>> What I added was to NOT provide alternatives to C++11 and simply 
>> require them which avoids the need to create variants for the 
>> different standards.
> Sure, because with your suggested change you are assuming a standard 
> of C++11 on up for boost::chrono and all Boost libraries which use 
> boost::chrono.

This is why I referenced the discussion of "Boost switch to C++11" in 
which the essence was: Any library who wants to stop maintaining old 
standards is free to do so.

 > 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.

This actually sounds like a reasonable way to do this in small steps. In 
the first release use boost::chrono types inheriting from std::chrono 
and implicit conversions from/to them which would already solve the 
interface problem: A boost library taking boost::chrono can no take 
either and boost libs can even switch to using std::chrono instead. And 
it would reduce maintenance costs as boost::chrono would considerably 
shrink down.