The main objection to the pull request was that a dependency was created. I'm sympathetic to that objection, I usually try to avoid explicit dependencies on Boost vs Std types and try to be interoperable with both. For instance, Boost.Interprocess timeouts can be used now with both Boost.Chrono and std::chrono types without including the corresponding headers, because you have the power of templates.
I had the same problem with boost::container::basic_string. Should I construct it from boost or std string_views? If you are in a generic, templated class, many times you can support both:
template<template <class, class> class BasicStringView> explicit basic_string(BasicStringView<CharT, Traits> sv, const allocator_type& a = allocator_type()) : base_t(allocator_traits_type::select_on_container_copy_construction(a)) { this->priv_terminate_string(); this->assign(sv); }
where assign is:
template<template <class, class> class BasicStringView> basic_string& operator=(BasicStringView<CharT, Traits> sv) { return this->assign(sv.data(), sv.size()); }
Then a) the user has to include the proper include (not your problem) and b) your component is free of any dependency c) Other StringView types can be plugged if they offer
I don't know if the proposed templated conversion operator would work flawlessly in all cases but I suggest we take this or similar templated approach so that utility/string_view does not depend on std::string_view, and we can then have a single string_view type in Boost.
This is not viable for std::format is it?