Re: [boost] boost.url review

...

I would either emphasize it in the docs, or rename the containers to something that reflects this fact (e.g. const_params and mutable_params, as asio does).

I would much rather emphasize it in the docs, because writing "const" and "mutable" over and over is bound to be a chore. Asio gets away with it because the mutability of buffers is central to the role of asynchronous operations but I'm not so sure the same applies here.

We are very happy to hear proposals for alternate container names, especially if they are complete proposals (give an alternative for each existing name) and if necessary what the url_view and url member functions would be renamed to.

I would suggest leaving url and url_view as-is, and replacing the "view" part for "const" for the rest of the containers: - params stays as is - params_view becomes const_params - params_encoded stays as is - params_encoded_view becomes const_params_encoded And so on; I'd leave the member function names as they are.

...

I don't know if this is a common use case, but I'd consider adding a function that simplifies it (i.e. params::set_value(string_view key, string_view value).

Yep, we need that! There are open questions (like what do you do if more than one key exists). Here is an open issue for it:

https://github.com/CPPAlliance/url/issues/412

Just commented there.

...

I'm not very keen on exposing the parsing infrastructure and helper functions (other than percent encoding/decoding) as public API, as I think it violates the principle of API surface minimization.

I feel you there but they have to go somewhere because the alternatives are worse. It isn't perfect, I know.

Are the functions intended to be used just by other Boost libraries, or also the general public? If the former is the case, could they not be separated into a BSL-licensed repository shared between libraries and just used as a submodule? I understand you don't want to put them into a separate Boost library because of the review process it would involve and the overlapping it would create, but I'd say a submodule repo could work-around it and not violate any of the Boost guidelines (AFAIK).

...

The documentation is good and the reference is complete, but I miss some examples.

Yep. Its not easy to come up with a complete application that just does stuff with URLs.

I would find this useful (this builds a QR code using Google's Infographic API): #include #include <iostream> using namespace boost::urls; int main(int argc, char **argv) { url u ("https://chart.googleapis.com/"); u.segments().insert(u.segments().end(), "charts"); u.params().append("cht", "qr"); u.params().append("chs", "600x600"); u.params().append("chs", argv[1]); std::cout << u << std::endl; } Regards, Ruben.