On Fri, Oct 15, 2021 at 5:15 AM Phil Endecott via Boost
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