Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
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
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
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
participants (2)
-
Glen Fernandes -
Howard Hinnant