On Thu, Sep 12, 2019 at 10:56 AM Dominique Devienne via Boost < boost@lists.boost.org> wrote:
On Thu, Sep 12, 2019 at 4:29 PM Bjorn Reese via Boost < boost@lists.boost.org> wrote:
On 9/12/19 3:19 PM, Mike via Boost wrote:
b) to conditionally enable support for std::string_view in c++17 (implicit conversion to and explicit construction from string_view)
For the string_view to bikeshedding_string conversion I would prefer a temmplated constructor that takes a container (a Range concept to be precise.) That way it works with any type that has begin() and end(), and we do not create a dependency on std::string_view. The container could be further constrained to those with value_type == char.
That's fine from std::string_view to fixed_capacity_string. But the reverse would be awkward, and not an implicit conversion to std::string_view, no? --DD
There are papers describing how the standard wants (is going) to do this, for both span and string_view: https://wg21.link/p1391 | https://wg21.link/p1394 Containers like bikeshedding_string were almost going to have implicit constructors from any range, but the paper was shot down and the new direction is using an explicit free function (https://wg21.link/p1206). This avoids shenanigans with overload resolution. But, since this is bikeshedding_string we may not need to worry about e.g. Allocator, and thusly the set of overloads will not be all of those in something like std::vector, but a much smaller set that can tolerate a templated range constructor on bikeshedding_string. Sincerely, JeanHeyd