Rename all fallible from_bytes functions to try_from_bytes

[sffc]

Many, or most, of our functions that are named from_bytes are fallible. @markusicu suggested that we follow the Rust convention of try_from_... to indicate a fallible function.

Thoughts?

• [ ] @zbraniecki
• [x] @Manishearth

[Manishearth]

Let's do it

[robertbastian]

There are also fallible functions that don't have a try_ prefix, like str::from_utf8, which I think is fairly similar to from_bytes functions.

[sffc]

Yes, FromStr::from_str and str::from_utf8 are counter-examples.

[sffc]

@Manishearth @zbraniecki does Robert's comment above change your opinion on this?

[zbraniecki]

Yes. I am moving to from_bytes as it matches from_str and from_utf8 and parsing is generally fallible so if there's no strict consensus in stdlib, I prefer shorter.

[Manishearth]

I would caution against looking to the stdlib for consistent naming, the stdlib fossilized names before conventions existed, often.

But in this case I think either is fine; I don't think the community has a strong preference.

[sffc]

I haven't expressed my opinion yet. I have a preference for try_ naming because that seems to be the newer convention.

[robertbastian]

I think the try prefix is only worth the extra typing if there's also an unprefixed fuction. So if we had from_bytes which panics, try_from_bytes would be the safe version of it. If we only have one function it should have a concise name. The fallability is part of the return type.

[sffc]

Choices:

1. from_bytes -> Result
2. try_from_bytes -> Result
3. try_from_bytes -> Result and from_bytes (panics)

• @Manishearth - I don't think we should have functions that choose to panic (gives reasons)
• @zbraniecki - If there is a combination of fallible and infallible possible, then separation makes sense; if the parsing of an input is always going to be fallible, then it's implicit. In a typed language like Rust, people are always going to get the right outcome.
• @Manishearth - The danger of people misunderstanding the functions is that they get a type error. I just don't think we should look at the standard library for naming advice.
• @sffc - TryFrom is a newer Rust convention. It's common for types to implement TryFrom but not From. I feel we should do the same here. But I'm also okay going with from_bytes based on the principle that parsing bytes is inherently a fallible operation, like parsing a string is inherently a fallible operation.
• @echeran - I like the consistency of try_from_bytes. It seems we should value consistency with TryFrom
• @sffc - Our constructors are called try_new and not new
• @aethanyc - I would say 2 > 1 >> 3. I like the consistency of naming with try_.

Decision: 3 votes for try_from_bytes (sffc, echeran, aethanyc), 2 votes for from_bytes (robertbastian, zbraniecki). Go with try_from_bytes.

[sffc]

Now that I'm in the middle of implementing this, I actually really like the try_from convention because it makes method chaining a lot easier to read. We often do Foo::try_from_bytes().map(...).map_err(...)? and it makes it a lot more clear where the Result originated from.