Re: My Boost.URL review

From: Seth (bugs_at_[hidden])
Date: 2022-08-22 11:26:41

> That doesn't look quite right, "localhost" should be the scheme and
> the path should be "5555" which of course is also not what the user
> likely intended but.. yeah.

That's why I like the more explicit parse functions. It makes the casual user aware that you can start your parse with different expectations.

> Well, I don't know that I would add a member function that performs an
> identical operation just as an alternative... BUT, there is a good
> use-case for a member function and that is to allow resolve where the
> base is also the destination. This is not currently allowed in the
> free function, because the base is received as a view. But as a member
> function of the owning containers (url, static_url) it can be done
> in-place - one user has already requested this.

That's a use case I hadn't even considered, I think the added discoverability is a nice side-catch. Perhaps the javadoc for one can refer to the other for maximum effect.

> A shame because I put the most effort into those docs :) I feel they
> are representative of the quality I would like to see for the rest of
> the documentation.

I will get to it some day. I do have a thing for parser combinators/generators, and for simple code :)

>>  - message for `error::success` returns arbitrary value:
>>     #4372 error.cpp(53) failed: 'BOOST_URL_ERR(error::success).message() == "success"' ('bad alpha' == 'success')
>
> That's weird, can you please open an issue?
Done https://github.com/CPPAlliance/url/issues/445 It's just a missing switch case. Perhaps we shouldleverage some compilers' ability to diagnose missing enumeration members in switches.