I’d like to suggest a refactor for parse_url_or_relative following the "parse, don't validate" pattern.

By introducing a Link type, we can remove the dependency on either and replace parse_url_text with a resolve_to method. This consolidates the prefix logic into a single pass.

pub enum Link<'a> {
    Absolute(Uri),
    Relative(RelativeUri<'a>),
}

impl<'a> Link<'a> {
    pub fn parse(text: &'a str) -> Result<Self, ErrorKind> {
        let text = text.trim_ascii_start();
        match Uri::try_from(text) {
            Ok(uri) => Ok(Self::Absolute(uri)),
            Err(ErrorKind::ParseUrl(ParseError::RelativeUrlWithoutBase, _)) => {
                let rel = if text.starts_with("//") {
                    RelativeUri::Scheme(text)
                } else if text.starts_with('/') {
                    RelativeUri::Root(text)
                } else {
                    RelativeUri::Local(text)
                };
                Ok(Self::Relative(rel))
            }
            Err(e) => Err(e),
        }
    }

    pub fn resolve_to(self, base: &BaseInfo) -> Result<Url, ErrorKind> {
        match self {
            Self::Absolute(uri) => Ok(uri.url),
            Self::Relative(rel) => base.resolve_relative_link(&rel),
        }
    }
}

Not too happy with the term Link. We could also call it InputUri or something.
And parse could also be a TryFrom, but you get the idea.

Does this make sense? Sorry, not too deep into that topic, so there's a high chance I'm missing important context.

Parse don't validate (PDV) is about encoding properties that have been checked into the type itself and avoiding overly general types like String.

The refactor you suggested doesn't increase PDV, because it's the same quantity of information just in different names (but if you do want different names, we can do that).

In fact, both my current code and your suggestion fall afoul of "names are not type safety" because we've just given a name to &str without constraining what's inside the string.

As you noted, the slicing &x[1..] could panic on general strings. But it was my intention (and I wrote in the doc comments) that SchemeRel should always start with //, so this should be safe. But this is an example of a validated, not parsed, property so it's not guaranteed in the types.

If we were to increase PDV, that would look like replacing the &str inside SchemeRel with a specific type that knows it always starts with //. Something like SchemeRel(StrWithPrefix<'a, "//">) - using const generic parameters. This would give us more safety and guarantees.

This could be done using something like refinement types - specifically, a StartsWith predicate. Or, if that's too heavy, I can write a basic type myself. Or, we just use unwrap_or :)

You're right. Let's dismiss that idea. So the only open point from my side would be #2078 (comment).