io: the `Error` trait could require the implementation of `Fom<ErrorKind>`.

[Conaclos]

std::io::Error implements From<std::io::ErrorKind>.
This is "intended for use for errors not exposed to the user, where allocating onto the heap (for normal construction via Error::new) is too costly".
This seems well suited to the context of embedded systems.

What do you think about requiring the implementation of From<embeddedd_io::ErrorKind> for the embeddedd_io::Error trait?
This is a breaking change because this could require to all implementation of a custom Error to also implement From<embeddedd_io::ErrorKind>.

[Dirbaio]

i'm not convinced, for 2 reasons:

1. what is the use case? The usual flow of error handling is: impl produces an instance of Error, user receives it, does .kind() to inspect which ErrorKind it is, then match on that. In what case would the user need to go from from ErrorKind to Error? It's going backwards in the error handling flow.
2. Many impls can only fail in a subset of ways. What would the From impl do when converting from a kind that the impl would normally not generate? It's forced to add an Other variant or similar. Or what's more: some impls are infallible. You can't convert from ErrorKind to Infallible.

[Conaclos]

I took a peak in #691

what is the use case?

This allows to simplify error handling inside embedded-io. We can get rid of ReadExactError and SliceMutError, making embedded-io closer to std::io.

Also, ErrorKind offers an InvalidData variant. This allows users to emit errors of this kind.
This can also be useful of emitting Error::UnexpectedEof in some cases.

Many impls can only fail in a subset of ways. What would the From impl do when converting from a kind that the impl would normally not generate? It's forced to add an Other variant or similar. Or what's more: some impls are infallible. You can't convert from ErrorKind to Infallible.

I think you are right here. However, it is not how std::io is implemented. std::io uses a single Error type for all kinds of errors. If the goal of embedded-io is to mirror closely std::io, then I think we should require the implementation of From<ErrorKind> because this brings embedded-io closer to std::io:

• This allows to remove ReadExactError and to replace it with ErrorKind::UnexpectedEof. This is what std::io does.
• This allows to remove SliceMutError and to replace it with ErrorKind::StorageFull.

It is not possible to return Infallible error in std::io. Thus, I think we should just discard the implementation of Error for Infallible. This avoids the issue you cited.

[Dirbaio]

The goal of embedded-io is to match std::io as much as possible, except in things we've intentionally chosen to deviate. Error handling is one of such things:

std::io has:

• An ErrorKind enum
• An Error type, the same type for everyone.

embedded_io has:

• An ErrorKind enum
• An Error trait
• Each impl provides its own custom error type, with the ErrorType::Error associated type.

The reason for this is memory efficiency and performance. Impls that can only fail one way can use unit structs like SliceMutError, which are zero-sized. Impls that can never fail can use Infallible. This makes Result<(), Infallible> zero-sized, since the Err variant gets optimized out. Simplifying return values like this also saves code size, since there's less branches needed for checking things.

We could've gone the std::io route and defined a single Error type and force everyone to use it, but it'd have been unnecessarily limiting and/or wasteful. Impls may want to return custom errors that aren't covered by any ErrorKind, so we'd have to make it flexible enough for everyone. std::io::Error does it with

• string error messages, which would waste memory for impls that don't need it
• Box<dyn Error> which requires alloc and causes bloat due to vtables.

so this is not viable.

Given that we've decided to deviate, we should do what makes the most sense with this difference, and not do things just "because std::io does it" because even if they make sense for std::io they don't necessarily make sense for the way embedded-io does error handling.

Also, ErrorKind offers an InvalidData variant. This allows users to emit errors of this kind. This can also be useful of emitting Error::UnexpectedEof in some cases.

Not sure what you mean here.

• Impls can already emit whatever error they need, they've defined the actual Error type they use and can emit any error without needing any From impl.
• Users don't emit io errors, they receive them. If they want to either forward io errors up or emit their own they can make their own enum that contains the io error plus their extra errors.

This allows to remove ReadExactError and to replace it with ErrorKind::UnexpectedEof. This is what std::io does.
This allows to remove SliceMutError and to replace it with ErrorKind::StorageFull.
It is not possible to return Infallible error in std::io. Thus, I think we should just discard the implementation of Error for Infallible. This avoids the issue you cited.

This increases memory usage.

[Conaclos]

Thanks for your detailed answer.

The reason for this is memory efficiency and performance.

TBH I am unsure to see the benefit of this optimization. The bottleneck is likely to be the I/O (file I/O, network I/O, ...).

Impls that can only fail one way can use unit structs like SliceMutErro

Perhaps, I am missing the main goal of the crate. To me implementations like impl Read for &[u8] are mostly here for testability or edge cases? Isn't File/Network IO abstraction the main reason d'être of embedded-io?

We could've gone the std::io route and defined a single Error type and force everyone to use it, but it'd have been unnecessarily limiting and/or wasteful.

I must admit I am not fond of the std::io approach: std::io::Error looks too flexible.
I would prefer to crate custom error and to encapsulate the std::io::Error in the custom error.

I have some difficulty to use this approach with embedded-io because the error type is generic. What do you suggest for this kind of usage?
The approach I am currently using is:

#[derive(Debug)]
struct CustomError<E> {
  Custom,
  UnexpectedEof,
  Io(E),
}
impl<E> From<E> for CustomError<E> { ... }
impl<E: embdedd_io::Error> embdedd_io::Error for CustomError<E> { ... }

fn read<R: embdedd_io::Read>(reader: &mut R) -> Result<(), CustomError<R::Error> { ... }

This increases memory usage.

Regarding ReadExactError, I don't think this increases memory usage. This should be the same.
Regarding SliceMutError, yes because it is no longer a zero-sized type. However, ErrorKind (a u8) is quite cheap.