Expand description
Traits to access a CRI (or CRI reference) using accessor methods.
While a CRI could be implemented with type state (where a full CRI has a .pull() that gives a scheme and a tail), this makes needlessly complex and verbose code.
The hope with the sketched API is that when used on, say, a CRI that’s a plain memory slice (or
pointer to a known-wellformed CRI, as they are self-delimiting), for which calling .path()
would incur a call to .host_and_pathindex() and in turn to .scheme_and_hostindex(), that a
program that calls .scheme(), .host() and .path() in succession would be understood by the
compiler to remove the costly nested calls and use the already-available results. Analysis of a
compiled program will be required to see whether that is actually done.
This may need some help from constification and #[inline] annotations.
Compared to a type-stated version, this is easier to use when not trying to squeeze the last bit of performance, but may be harder to use when squeezing (for there might be some manual labor involved to ensure that, for example, noting too register heavy is done between iterating over the path and asking for the query).
Structs
A resolved CRI computed from a base and a reference on demand
Enums
The different values the discard component of a CRI reference can have