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.