Re: Boost.URL: Something Wicked This Way Comes!

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2021-10-15 15:13:16

On Fri, Oct 15, 2021 at 5:15 AM Phil Endecott via Boost
<boost_at_[hidden]> wrote:
> Exactly, it's like returning a string_view from a function - which
> you should never do, at least not without an obvious indication...

All functions in url_view which return encoded parts have a
string_view return type...

> > Maybe having parse_url_as_view(str) and a safer parse_url(str) using
> > the former but not returning a view would satisfy you?
>
> Yes, that's exactly what I suggested.

How would you convert this code to use "safer parse_url(str)"?

    url_view         u1 = parse_relative_ref( "/" ).value();
    url              u2 = parse_relative_ref( "/" ).value();
    static_url<1024> u3 = parse_relative_ref( "/" ).value();
    pmr_url          u4 = parse_relative_ref( "/" ).value();
    dynamic_url<
        std::allocator<char>> u5 = parse_relative_ref( "/" ).value();

> The alternative is to try to find some way to return something that
> can't be assigned to auto. This may be possible with something like
> a private_url_view class that wraps a view and makes everything private:

This sounds like an awful lot of try-hard. string_view is one of those
controversial types which is going to split people into two camps. I'm
of the camp that you have to be careful how you hold the knife. Rather
than put the library through contortions with questionable degrees of
effectiveness at solving the "problem" I think it is just easier and
more straightforward to say that ownership of strings is simply not
transferred using parse functions or url_view.

Thanks