Implement From for FromBytesWithNulError

[SUPERCILEX]

Needed for #93668 and generally useful.

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[SUPERCILEX]

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[SUPERCILEX]

r? @joshtriplett

[joshtriplett]

Trait impls can't be marked unstable; I posted a suggestion to address that. With that applied, r=me.

[SUPERCILEX]

Sounds good, done!

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

Concerns:

• Which ErrorKind? (Implement From for FromBytesWithNulError #96104 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[m-ou-se]

@rfcbot concern Which ErrorKind?

I'm not sure if InvalidInput is always the correct error kind for FromBytsWithNulError. I can imagine situations where InvalidData or UnexpectedEof or InvalidFilename would make more sense.

[m-ou-se]

Also note that io::Error::new(io::ErrorKind::InvalidInput, e) will do two allocations as it effectively allocates a Box<Box<dyn Error>>.

[SUPERCILEX]

@rfcbot concern Which ErrorKind?

I'm not sure if InvalidInput is always the correct error kind for FromBytsWithNulError. I can imagine situations where InvalidData or UnexpectedEof or InvalidFilename would make more sense.

Ah, so are you suggesting that From shouldn't be implemented at all and you should instead always choose the ErrorKind and message? If so that makes sense and I'll close this PR.

[dtolnay]

Independent of the question of which ErrorKind is correct, I think I would prefer not to add this impl. From what I've seen in serde, folks looking for impl From<?> for std::io::Error are most often doing it because they are cutting corners by using std::io::Error as an error type in code that has at most a little to do with i/o. If they value that concise ability to use ?, they should instead use an error type that has a generic impl<E: Error> From<E> instead of needing each implementor of std::error::Error to provide its own individual conversion to std::io::Error.

[SUPERCILEX]

Lol, that's literally what I'm trying to do. :) (Though in my case it's justified because I do have to return io::Error.) Anyway, I think this is enough feedback in the negative direction to close this PR.