N3975 -- URI

[Jeffrey Yasskin]

http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3975

This one I'm cross-posting to the networking mailing list since there
are comments about both the library and networking aspects.

* What encodings for URIs are used by other systems? Given that most
of a URI is in a subset of ASCII, and we can't know what encoding the
path or query are in, it seems unwise to provide lots of options for
character types or pick an encoding based on them. (You don't define
any IRI support in the normative wording, but even IRIs are encoded
into ASCII. It makes sense to be able to get the decoding into a
string, and maybe even cache that, but that's different from
overloading the whole-uri constructors for several encodings.)

* Are URIs immutable? Does copying a URI use the original allocator or
the default allocator? If the original, how?

* "Returns a uri object with the file scheme and the absolute path to
p. If p is absolute, the result is an absolute URI with a scheme file.
If p is relative, the result is a URI relative reference." is
inconsistent.

* "If u is an absolute URI with the file scheme, the result is a
experimental::filesystem::path object with an absolute path given a
uri." <- "given a uri" is probably extraneous.

* std::uri doesn't appear to be a literal class, so it can't have
constexpr members.

* A `port<>` template is probably too complex. Do any existing URI
schemes define more than a 16-bit port? int_least32_t is probably
plenty. Just `unsigned` is probably fine.

* Several of the `optional<>` wrappers may be too much too. How many
users want to distinguish between `https://foo` and `https://foo/`? Or
between `https://foo/bar` and `https://foo/bar?`? Contradicting some
advice I probably gave you a couple years ago, I'm tempted to prefer
`string_view` accessors that map missing to empty, and `has_foo()`
accessors to see whether the element was present.

* When referring to RFCs, please provide a link. The TS editors don't
want to have to guess. Links on every reference would also help people
trying to read the paper.

* Please use better names than `u` for arguments to functions like
`make_relative()`. What's the meaning of that parameter?

* "Postconditions: !empty() && is_absolute()" seems wrong for
`url(Source)`. How can you guarantee it's absolute?

* For `is_opaque()`, "true if the URI is absolute and its scheme is
not hierarchical" is not "Equivalent to !is_hierarchical()." A
relative URL would return false for both.

* "u.normalize(level).compare(u, level) == 0" isn't really a
postcondition on the normalize function. We don't have a function
attribute for "axioms".

* Can you specify the non-allocator variants in terms of the allocator
variants? It'd halve the size of many of your function definitions.

* Similarly for the error_code variants.

* The order of `u` and `v` in the `make_relative` examples is
inconsistent, and inconsistent with the `u.make_relative(v).resolve(v)
== u` axiom, which is itself inconsistent with the claim that "*this
as the base URI". Figure out what you mean.

* "https://foo.com/".make_relative("https://bar.com") should probably
return "//foo.com". You've specified an exception, but scheme-relative
URLs exist.

* The builder needs to specify how it encodes various parts of the
URI. e.g. is the host Punycoded? Is everything %-encoded as
appropriate for the part of the URI?

* uri_builder::uri() should probably be able to avoid allocations if
the builder is an rvalue.

* Be consistent about allocators. Either use them for uri_builder, or
take them out of the `uri` methods.

* Are filesystem URIs really an important use case?

* Most functions disable the exceptions by passing an `error_code&`
argument. Perhaps the constructors should too?

Jeffrey