Consider a Port type for Uri::port()

[seanmonstar]

Users may wish to access the port as a string, and not just an integer. We have the string already, so we could provide a newtype around it, Port, and a user can then get the bytes themselves, or just ask for the integer.

fn port(&self) -> Option<Port>;

struct Port<'a> {
    bytes: &'a str,
}

impl<'a> Port<'a> {
    fn as_str(&self) -> &str;

    fn as_u16(&self) -> u16;
}

This would be for both Uri and Authority. Probably introduced as port_part(), deprecating port() to be replaced in 0.2.

[carllerche]

You'd probably want to add a bunch of PartialEq implementations as well.

[briansmith]

impl<'a> Port<'a> {
    fn as_str(&self) -> &str;

    fn as_u16(&self) -> u16;
}

These would be better as From/Into conversions.

[carllerche]

No reason to not have both!

[joshleeb]

@seanmonstar got a PR in progress for implementing Port as

struct Port<'a> {
    bytes: &'a str,
}

Is there any particular benefit to having bytes: &'a str rather than storing the port as a u16? Then we could have something like

struct Port {
    port: u16,
}

impl Port {
    fn from_bytes(bytes: &str) -> Option<Port>) {
        u16::from_str(bytes).and_then(|p| Some(p.into())).ok()
    }
    fn to_string(&self) -> String { self.port.to_string() }
    fn as_u16(&self) -> String { self.port } // Also impl From<u16> for Port {}
}

[carllerche]

The main reason would be to avoid parsing if not needed 🤷

[seanmonstar]

@joshleeb people can already get the u16 directly, the purpose of this type is for cases where you need the port but in string form. With only the u16 accessor, you have to allocate a new string via port.to_string(), but we already have the &str inside the Authority.

[joshleeb]

Do we want to pull out the valid port number, as a &str and store it in the Port struct? Something like

pub fn new(bytes: &'str) -> Option<Port<'a>> {
    bytes
        .rfind(":")
        .and_then(|i| u16::from_str(bytes).ok())
        .and_then(|_| Some(Port{ bytes }))
}

Or do we just want to store the raw bytes, even if it's an invalid port number?

[seanmonstar]

Hm, yea, since the port isn't verified to be a valid u16 when parsing the full URI, it'd be weird to get a Port that couldn't be turned into a u16. Because of that, it does make sense to parse to a u16 first. Perhaps to not require parsing again, the Port could have a u16 field as well.