futures async support?

[yawn]

Just a quick gut check if you think that makes sense for the scope of leb128. Would make some of my code a bit more organic.

If yes, I can contribute an async feature which would add a gated dependency to futures for AsyncRead / AsyncWrite. Naively this would clash with #25 or rather no_std (if introduced).

[fitzgen]

I think it would be fine to have a couple variations of the read/write methods (one variation being async) that we can cfg-enable on/off as the appropriate cargo features are supplied.

[fitzgen]

They should all use the same underlying helpers as much as possible.

[yawn]

Most simple version would introduce approx the following changes:

• add futures as gated dependency
• add smol as dev dependency for tests
• convert the primary loops in signed / unsigned to macros with a) different bound variations, b) async / no async keyword (or maybe just returning Future) and c) await / no await
• re-create signed / unsigned with macros and feature gate the async variants

LMK if that sounds goods to you.

[fitzgen]

SGTM, modulo one thing:

convert the primary loops in signed / unsigned to macros with a) different bound variations, b) async / no async keyword (or maybe just returning Future) and c) await / no await

If possible, I'd rather refactor this so that the implementation is a series of little functions that each just do the computation between state transitions, and then the sync vs async methods would just glue them together slightly differently. This approach avoids macros, which I'd like to do as much as possible.

[yawn]

Like this (naming tbd.)?

    #[derive(Default)]
    struct ReadCtx {
        buf: [u8; 1],
        forward: bool,
        result: u64,
        shift: i32,
    }

    impl ReadCtx {
        fn unsigned(&mut self) -> Option<Result<u64, Error>> {
            if self.forward {
                if self.buf[0] & CONTINUATION_BIT != 0 {
                    return None;
                } else {
                    return Some(Err(Error::Overflow));
                }
            }

            if self.shift == 63 && self.buf[0] != 0x00 && self.buf[0] != 0x01 {
                self.forward = true;
                return None;
            }

            let low_bits = low_bits_of_byte(self.buf[0]) as u64;
            self.result |= low_bits << self.shift;

            if self.buf[0] & CONTINUATION_BIT == 0 {
                return Some(Ok(self.result));
            }

            self.shift += 7;
            self.buf = [0];

            return None;
        }
    }

    /// Read an unsigned LEB128-encoded number from the `std::io::Read` stream
    /// `r`.
    ///
    /// On success, return the number.
    pub fn unsigned<R>(r: &mut R) -> Result<u64, Error>
    where
        R: ?Sized + io::Read,
    {
        let mut ctx = ReadCtx::default();

        loop {
            r.read_exact(&mut ctx.buf)?;

            match ctx.unsigned() {
                None => continue,
                Some(res) => return res,
            }
        }
    }

[fitzgen]

Something like that, yes, although I suspect we might get better codegen if we passed all the struct's fields as arguments to each helper function (they won't be pub anyways so it seems okay).

[fitzgen]

But maybe with inlining and SROA that won't actually matter. So I guess just do the struct thing first and then we can profile and tweak things as necessary later.