On Mon, Aug 10, 2020 at 8:40 AM Dominic Fandrey via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I think it is probably an oversight and not intentional that those are not
> there:
>
> constexpr std::string operator +(std::string const &, std::string_view
> const &);
> constexpr std::string operator +(std::string_view const &, std::string
> const &);
> constexpr std::string operator +=(std::string &, std::string_view const &);
>

It was intentional. From N3512 (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3512.html):

> I also omitted operator+(basic_string, basic_string_ref) because LLVM
returns a lightweight object from this overload and only performs the
concatenation lazily. If we define this overload, we'll have a hard time
introducing that lightweight concatenation later.

string_ref was then renamed to string_view.


>
> I would even hope for this one:
>
> constexpr std::string operator +(std::string_view const &,
> std::string_view const &);
>
> I agree that implicit conversion from a view back to std::string invokes
> the danger
> of accidentally enabling an expensive std::string construction, but in
> this case
> I think it is clear that the operator must create a std::string instance.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>