Re: [container] static_string ?

From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-09-12 15:11:14

On Thu, Sep 12, 2019 at 10:56 AM Dominique Devienne via Boost <
boost_at_[hidden]> wrote:

> On Thu, Sep 12, 2019 at 4:29 PM Bjorn Reese via Boost <
> boost_at_[hidden]>
> 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