Should all conversion error types include the input? about http

[alexcrichton]

One alternative could be perhaps taking &Bytes instead of Bytes. That way an API which doesn't clone the input bytes (e.g. Version) wouldn't clone anything whereas other APIs (like HeaderName and such) would clone.

[carllerche]

Relates to #23

[alexcrichton]

I would personally recommend "no" here. I think for generics it might matter but it looks like nothing is generic in this crate:

$ rg -- '-> Result'
src/status.rs:    pub fn from_u16(src: u16) -> Result<StatusCode, FromU16Error> {
src/status.rs:    pub fn from_bytes(src: &[u8]) -> Result<StatusCode, FromStrError> {
src/status.rs:    fn from_str(s: &str) -> Result<StatusCode, FromStrError> {
src/uri.rs:fn parse(s: &[u8]) -> Result<Marks, ErrorKind> {
src/uri.rs:fn parse_scheme(s: &[u8]) -> Result<(Scheme, usize, &[u8]), ErrorKind> {
src/uri.rs:fn parse_authority(s: &[u8], pos: usize) -> Result<u16, ErrorKind> {
src/uri.rs:fn parse_full(s: &[u8]) -> Result<Marks, ErrorKind> {
src/uri.rs:fn parse_query(s: &[u8], pos: usize) -> Result<(u16, u16), ErrorKind> {
src/uri.rs:    fn from_str(s: &str) -> Result<Uri, FromStrError> {
src/method.rs:    pub fn from_bytes(src: &[u8]) -> Result<Method, FromBytesError> {
src/method.rs:    fn extension_inline(src: &[u8]) -> Result<Method, FromBytesError> {
src/method.rs:fn write_checked(src: &[u8], dst: &mut [u8]) -> Result<(), FromBytesError> {
src/header/value.rs:    pub fn try_from_str(src: &str) -> Result<HeaderValue, InvalidValueError> {
src/header/value.rs:    pub fn try_from_bytes(src: &[u8]) -> Result<HeaderValue, InvalidValueError> {
src/header/value.rs:    pub fn to_str(&self) -> Result<&str, ToStrError> {
src/header/name.rs:    -> Result<HdrName<'a>, FromBytesError>
src/header/name.rs:    pub fn from_bytes(src: &[u8]) -> Result<HeaderName, FromBytesError> {
src/header/name.rs:    fn from_str(s: &str) -> Result<HeaderName, FromStrError> {
src/header/name.rs:    pub fn from_bytes<F, U>(hdr: &[u8], f: F) -> Result<U, FromBytesError>

The only generic there, HdrName::from_bytes, isn't exposed publicly. Otherwise everything else is just parsing strings/bytes it looks like. In the standard library for Utf8Error returned by str::from_utf8 only contains indexes.

What we could capture is the lifetime of the input into the output (e.g. add lifetime parameters to error types) but I think tha'd be less ergonomic to work with

So basically:

• I don't think there's any generics to capture today (unless I missed one?)
• I don't think we should capture lifetimes
• If we really want to convey indexing/extra information, we can do so with indices backwards-compatibly

In that sense I'd be ok with closing this issue with no further action. Thoughts?

[alexcrichton]

cc #58, some more thoughts on errors

[carllerche]

@alexcrichton the main "issue" is if you pass in a Bytes by value, you will lose the handle if there is an error. It's not super critical because cloning is shallow, so you can always clone before you try to convert if you really want to hold on to the input on error.

I don't care strongly either way right now, so I'm fine w/ not returning the input.

[alexcrichton]

Conclusion from discussion yesterday: We should add "owned" variants of errors where the input is Bytes, but otherwise punt for now. We won't add functions to retrieve the Bytes yet, we just want to have the opportunity to add these functions later.

[carllerche]

But before releasing 0.1, any conversion from Bytes has to have a separate type (though, w/o necessarily exposing the inner Bytes yet). Otherwise, it would be backwards compat breaking?

Edit: that's what #65 does.

[alexcrichton]

Oh certainly! That's #65