On 2020-01-21 18:51, Vinnie Falco wrote:
On Tue, Jan 21, 2020 at 2:13 AM Andrey Semashev via Boost
wrote: I'd be more interested in a more generic URI library. Along with a few associated algorithms, e.g. those described in: https://tools.ietf.org/html/rfc3986
Yes, this library does that. I do not use the term "URI" because it is confusing and pointless. They are all URLs now. My library follows the RFC, except that I have renamed the top level production rules to reflect this preference:
URL = scheme ":" hier-part [ "?" query ] [ "#" fragment ] URL-reference = URL / relative-ref absolute-URL = scheme ":" hier-part [ "?" query ]
I didn't invent this idea, deprecating the word "URI" and using "URL" consistently in its place is recommended by WhatWG.
There is a semantic difference between URI and URL - the former is an identifier and the latter is a locator (i.e. a path to a resource location). You can treat locator as an identifier but not the other way around. Using the term URL to refer to an URI is confusing. The reason I'm interested particularly in URIs is because I have to deal with them, not so much with URLs.
Why not uri and uri_view.
First, I don't use the term "uri" ever. But i think you're asking, why not "url" and "url_view?" Because `url::url` and `url::url_view` look bad, they repeat a word. Thus we have `url::view` and `url::value`, which are sensible.
Well, no, not really. I know 'using namespace abc;' is not something universally welcome, but its is a valid use case nonetheless. After that having `view` and `value` is no longer sensible. I would still prefer `boost::uris::uri` and `boost::uris::uri_view`. Note that the namespace is plural.