On Wed, Aug 24, 2022 at 1:04 AM Andrzej Krzemienski
This convinces me even further that I might want a type like http_url with a tighter invariant:
Uhh.. I don't know about that. The request-target in HTTP is not exactly a URL. From rfc7230: request-target = origin-form / absolute-form / authority-form / asterisk-form origin-form is a relative-ref which has no scheme or authority. There's no port in it. absolute-form is the same as absolute-URI which can have an authority. authority-form is just an authority, can have a port, and is technically not even a URL. That's why Boost.URL provides the type authority_view and the function parse_authority. And asterisk-form is literally just a single asterisk character '*' which is also not a URL. Boost.URL does not provide a type or parser for this because, well come on man you can parse that yourself :) So what would http_url be? It can't be all of these things.. unless maybe you're thinking to make it a variant. I feel that the current model of providing url_view, url, and static_url as general purpose containers which faithfully implement rfc3986, while leaving it to the user to build up tighter invariants or other scheme-specific interfaces to the general container, strikes a reasonable balance. On a side note, it is because the specifics of the grammars matter so much for where they are used that I have been strict in the naming of parse functions. It is essential to use the right terms or else more confusion results. Did you know that the request-target was sometimes not a URL, and has a grammar that is dependent on the context (e.g. GET versus CONNECT)? I did not... Users will need to know these things in order to produce correct programs, and Boost.URL does its part by being precise. Thanks