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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2021-10-21 13:46:52

Ahmed Charles wrote:
> On Friday, October 15th, 2021 at 5:14 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...
>
> My primary objection to this line of thinking is that the 
> standard begin/end functions have the same dangerous 
> implications as this function does. The input can be a 
> string and the output is something that becomes invalid 
> when that string is destroyed.

I'd be happy with the parsing function returning a view if
its name reflected that. My complaint is that the short name
parse_url() doesn't give the user that "obvious indication".

There are a couple of differences with begin()/end(). Firstly,
"everyone knows" that begin() and end() return iterators so
the names do give the required clue. Secondly, these are
methods, not free functions; you can argue that it's OK to
return iterator/pointer/view types from getter methods if
the lifetime of the pointee is the same as the object. (Yes
I'm conveniently overlooking the begin()/end() free functions.)

I'd also suggest that the existence of foot-guns already in the
language is not an excuse for adding more!

These are not absolute, yes/no decisions; there are trade-offs
to be made. The only benefit of naming this view-returning
function parse_url() is less typing. I don't think that's
worthwhile.

Regards, Phil.