Tracking Issue for version 2.0

[dkales]

After we have merged #20 now, what is still open for a version 2.0?

• General Effort to fix all clippy errors?
• Use native int load and store instead of homegrown bitshifts #18 should also probably be merged and seems ready?

[faern]

You can set up a milestone on github instead if you want to. A more built in way of tracking a set of issues.

[faern]

I'd like to have a discussion about #21 vs v2. I'll copy my comment from the other thread:

Should we try to fix all variants in the same binary for v2 also or do we postpone that to v3? I think the current design with just a single variant is extremely limiting in how you can use this crate. But rewriting that part is also not going to be trivial, and having v2 soon would be great. So depend on how fast you are comfortable going from v2 -> v3.

[Colfenor]

What exactly are we defining as goal for General Effort to fix all clippy errors?. It probably can be split up into sub-tasks since as what @prokls mentioned some clippy errors,

such as you are trying to use classic C underflow conditions that will fail in Rust might take additional discussion / effort in order to be fixed

concerning refactoring some loops i'll try to submit a PR soonish

[dkales]

I guess the end goal is that the CI test passes, i.e., cargo clippy -- -D warnings returns 0.
Most of them are sensible to address, for some it might be better to just add a #[allow(clippy::bla)] annotation

[Colfenor]

Oh I almost forgot, last but not least I'd recommend for the final release of v2.0 to update the README.md with the latest benchmark results

[prokls]

Done, v2 is merged into main and now the main branch. v1 branch was created.