io::Error should be usable without allocation

[jethrogb]

In the mean time, see https://crates.io/crates/core_io

[Ericson2314]

I'd prefer a plan like the one outlined here rust-lang/rfcs#2262 where we introduce core::io Read/Write traits with an associated error type, and then blanket impl the std::io ones in terms of that.

IMO the big fat error types like io::Error are an untyped kludge inherited from Unix and friends. There's no reason to be so coarse-grained on greenfield systems and I'd hope we could allow the standard library to support that. Also, even on conventional systems, it can be nice to know that e.g. the methods on slice won't fail. Finally, by putting versions of those traits in core, we can move more functionality below the platform-specific layers. As platform-agnostic code, that's where they both should be IMO, but practically, that allows them used by those layers which makes writing those layers much easier.

[Ericson2314]

rust-lang/rust#35121 fwiw if my !-based plan is to be taken, it would be nice if we could hack in !: From<_>, but we only have until beta hits stable!

[japaric]

I'd prefer a plan like the one outlined here rust-lang/rfcs#2262 where we introduce core::io Read/Write traits with an associated error type, and then blanket impl the std::io ones in terms of that.

Could the portability WG make an official-ish crate (or bless one of the existing ones) for that (Read/Write traits with associated types)? in the issue tracker of that crate / repo we could discuss whether we want to land them in the official core.

I have wanted those traits before and I'd rather not create and maintain such crate. I'm pretty sure I've seen at least one crate that defines such traits on crates.io and I think I've also seen those traits defined in the std implementation of some OS thing (?). We should all agree on a single definition of those traits, IMO.

[glandium]

There's core_io (https://crates.io/crates/core_io) but it's autogenerated at build time, which is not nice for vendoring.

[japaric]

There's core_io

That crate does not have the Read / Write traits with associated Error types. It has a port of std::io::Error to core.

[Ericson2314]

@japaric Well of course I'd be happy to clean up my own https://github.com/QuiltOS/core-io and make it official /s.

In seriousness I'd to first gather consensus we're on board experimenting with this (maybe with an eRFC), and then implement on a branch/fork in the actual repo. The finer-grained design details would be pend on what we discover during the implementation, as it's nigh impossible to predict without actually doing the work, and a waste of effort to expect an implementation first.

[Ericson2314]

@fluffysquirrels picking up from rust-lang/rfcs#2262 (comment)

Regarding Read::read_to_vec and similar, perhaps core::io could have a feature flag to toggle features that require alloc.

I don't think the feature flag is so good because then every instance also needs the feature flag. For example, there are uses for these core::io in situations where dynamic memory management (real time systems). Many instances for such things could also be extended with Read::read_to_vec, and I think it's easier to just optionally depend on alloc to write that optional impl, than optionally depend on your dependencies feature flag to depend on alloc and also directly optional depend on alloc, and and optionally include the method with the impl. And if the where clause on the impl is more restricted in the alloc case, then even more cfg machinery is needed!

[fluffysquirrels]

Optional dependencies and feature flags are very similar (cargo docs on features), so whichever is fine. If you have downstream dependencies that optionally use alloc/std, I think you may need feature flags to toggle their options.

Last I looked importing alloc in a no_std crate actually required a crate attribute #![feature(alloc)] rather than a dependency in Cargo.toml, but this may have moved on.

I have worked with no_std, no alloc crates for microcontrollers, and personally I found that feature flags are straightforward to use once you implement your first one and get used to the recipe:

• Add a feature flag to cargo.toml
• Document feature flag in crate lib for consumers
• Optionally specify the feature flag for all your dependencies that require it
• Add [cfg(...)] blocks to all relevant items in source code