Collecting iterator in no_std

I had tried using arrayvec, which works great but because it uses const generics bumps minimum rustc version beyond that of any of my dependencies, which is currently at 1.32.

Or really maybe I should just figure out a way to compare an array iterator, and another iterator type for equality, thought maybe someone might have some suggestions on crates I should look at.

You can always use an old version that doesn't use const generics, if needed: https://docs.rs/arrayvec/0.5.2/arrayvec/struct.ArrayVec.html

(But really, just bump MSRV. Especially if you're trying to be no-std, the goodness of usable arrays is so worth it.)

2 Likes

Indeed, normally I would but given that its just stuff entirely inessential to the crate, I don't want to bump just for that. But if this crate ever picks up a real need for arrays certainly.

Thanks I will try an old version!

FWIW, I basically ended up going with an ad-hoc macro using core::iter::Iterator::zip,
because both itertools and that old arrayvec would push it to unstable on the old compiler.

    macro_rules! check_eq {
        ($a:expr, $b:expr) => {
            for (x, y) in core::iter::Iterator::zip($a, $b.iter().cloned()) {
                assert_eq!(x, y)
            }
        };
    }

Only 30-39% of all crates are compatible with Rust 1.32, and that includes many old and abandoned crates. If you look only at actively maintained crates, you may be literally the last person still writing for it:

You may be unnecessarily adding yourself extra work. Pulling in an old arrayvec is going to add duplicate crates to people's projects, because they're likely to have the latest arrayvec too.

Absolutely and I appreciate you mentioning that.

I wouldn't bring it in if it was a dependency, but it was a dev-dependency, the actual crate doesn't depend on anything but num-traits and core which haven't changed at the pace of the rest of rust.

I just didn't want to release something which ostensibly works but none of its dev-dependencies do, and it was easy enough to fix without any additional dependencies.

Anyhow I think too much ink has been spilled on this already

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.