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

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2019-08-12 12:53:59

There is truth to this rationale, but I also wanted to point out that it is not absolute.  The C++20 additions to chrono were prototyped external to a C++14 chrono implementation:

    https://github.com/HowardHinnant/date

This included new “predefined” duration types, time_point aliases, duration and time_point I/O, new clocks, calendrical functionality and time zone functionality.

Not providing a boost implementation does not preclude enhancing a std::lib.  But it can certainly help in changing existing signatures, such as adding conditional noexcept in a ton of places.

Howard

On Aug 12, 2019, at 7:29 AM, Glen Fernandes via Boost <boost_at_[hidden]> wrote:
> 
> There is value in Boost.Chrono providing a chrono implementation (i.e.
> not just aliasing std::chrono), to provide a library where future
> enhancements to chrono could eventually make it into C++23, or beyond.
> i.e. Similar to how we enhanced std::shared_ptr, std::make_shared,
> std::allocate_shared past the C++11 versions, and these enhancements
> made it into C++17 and C++20.
> 
> Other Boost libraries can switch today to use std::chrono instead of
> boost::chrono (conditionally or unconditionally) if they want.
> 
> As always:
> - It is, up to the maintainer of Boost.Chrono whether he wants to use
> std::chrono internally, and make boost::chrono compatible with
> std::chrono.
> - It is up to the maintainers of other Boost libraries whether they
> want to use std::chrono instead of boost::chrono
> 
> Both of these can be achieved independently, purely by convincing the
> respective Boost maintainers. Maybe they can drop C++11 support and
> only support std::chrono. Maybe they might want to use boost::chrono
> in C++03 mode and std::chrono in C++11 mode.
> 
> The discussion on the Boost mailing list (each time it gets repeated,
> for Boost.X library for which there is a C++ standard library
> equivalent) while still interesting, probably still won't achieve
> anything. i.e. No amount of discussion here is going to result in any
> action to command any maintainer to do something.
> 
> Glen
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost