Use iovec instead of std::io in no_std builds?

[cbeck88]

Until #263 was merged in June, tokio-rs/bytes could have built cleanly as a no_std library, grabbing Vec etc. from the alloc crate.

After the move to std::io::IoSlice, it becomes impossible for the crate to expose the same interface in std mode and in alloc mode, so either we can no longer support no_std development or we must embrace features that are not additive... both of which are pretty painful in projects that do no_std development

Can we bring back the iovec dependency as an optional dependency and use it instead of IoSlice, when available? That will make it easier to use bytes in projects that build some targets as no_std and some targets as std. I can describe my usecase in more detail if that is helpful, but these kinds of interface changes across no_std and std are the source of a lot of pain especially for example in serde

[carllerche]

Why would it not be sufficient to feature gate those fns on a std feature?

[cbeck88]

There might be libs that use bytes that use those functions, that would be portable to no_std environment, if iovec were still used

If I had such a lib that I needed to use in no_std environment, I would be tempted to essentially revert #263 and use bytes that way, to get my dependency to work.

I guess it would also work to just pin bytes at 0.4, but if they've already switched to IoSlice then it won't work

[cbeck88]

Maybe you are right, there might not be a real use-case for this, if the user of bytes has already switched to std::io::IoSlice then there won't be any easy way to port them. It just seems to me that if IoVec is portable and IoSlice isn't then #263 was a loss

[cbeck88]

I think we should close this, sorry for noise

It's really too bad they didn't put IoSlice in core or alloc or something if it would have worked there.

I think that since you already have some partial dependency on std::io for the Reader etc. functions, there is no way to avoid having an std feature and using feature gating if you want to build in no_std environment. So it's not that much worse to just use IoSlice and feature gating for that as well, and it's a lot more complicated to have both IoSlice and IoVec in the mix