Could op's proposal be expanded to help in similar situations involving
function calls, i.e. https://godbolt.org/z/KtDH9r ?

On Thu, Dec 19, 2019 at 2:46 PM Ville Voutilainen via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, 19 Dec 2019 at 21:35, Andrew Tomazos <andrewtomazos_at_[hidden]>
> wrote:
> >
> > On Thu, Dec 19, 2019 at 2:22 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> On Thu, 19 Dec 2019 at 21:09, Andrew Tomazos via Std-Proposals
> >> <std-proposals_at_[hidden]> wrote:
> >> >
> >> > I think this is a problem worth solving. Its against a C++ design
> principle that built-in references (like const std;:string&) have the
> lifetime extension feature, whereas user-defined reference-like classes
> (like std::string_view) do not. In particular, this is one the arguments
> against migrating from const std::string& to std::string_view.
> >> >
> >> > I encourage you to submit a proposal for C++23:
> https://isocpp.org/std/submit-a-proposal
> >>
> >> We already have one:
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1179r1.pdf
> >
> >
> > That's interesting Ville, thanks - but (correct me if I am mistaken) I
> think what Herb is suggesting are tools to better diagnose a "dangling"
> std::string_view. I think what the OP is proposing is a core language
> feature that makes std::string_view lifetime-extend its referent (like
> const std::string& does).
>
>
> Correct, the approaches are different.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>