Howard wrote:

There is truth to this rationale, but I also wanted to point out that it is not absolute. [snip] Not providing a boost implementation does not preclude enhancing a std::lib. But it can certainly help in changing existing signatures,

Indeed. Of course, someone who wants to prototype some breaking change to a library like chrono or smart_ptr can do it without Boost. For example, we could have reimplemented ALL of shared_ptr in github/JohnDoe/smart_ptr to prototype the extensions added in C++17 and C++20. But here were some advantages of not doing so, and using Boost instead: - NOT reimplementing ALL of shared_ptr - Access to a bigger user base than github/JohnDoe/smart_ptr would have e.g. * Boost being white-listed as approved open source in many organizations * New versions of Boost included in many Linux distribution software repositories * etc. So it was an easy choice to go through Boost because boost::shared_ptr wasn't just an alias for std::shared_ptr, and had a quality, well tested, implementation. Still, even with Smart_Ptr, you have the option to convince the maintainer of Smart_Ptr to make boost::shared_ptr just an alias for [C++17] std::shared_ptr, and make boost::allocate_shared just defer to [C++20] std::allocate_shared. It would make users unhappy. There are already users of boost::local_shared_ptr which depends on the implementation of boost::shared_ptr, that would continue using Boost even after C++20 features are implemented everywhere. Glen