Checklist for version 0.3.0

[AaronKutch]

Here are the PRs that will need to be done before the crate is in a state that could be released.

• [x] Rust edition 2018
• [x] Rustfmt PR
• [x] Fix constants from digit.rs usage
• [x] Gather the standard ops trait implementations from around the library and put them in std_ops.rs
• [ ] #41
• [ ] Extract the shift operations and use the redesigned ShiftAmount from PR #36 to fix issue #28 and issue #23
• [x] Replace the Bit construct to directly use booleans and figure out what functions to keep for issue #42
• [x] Use NonZeroUsize (#39)
• [ ] Use MaybeUninit
• [ ] Fix big and little endian problems (#20, fix the from_vec_u64 TODOs)
• [ ] Better constructors (#44) (not the arbitrary concatenation stuff, only constructor stuff)
• [ ] Extract the multiplication and division code from arithmetic.rs into mul.rs and div.rs to use the simplified design from PR #36. This will also fix the remaining warnings and clippy warnings #48.
• [ ] Extract the fuzz tester into fuzz.rs. #47 is unfortunately going to go unfixed until Rust fixes and stabilizes stuff related to RFC #2091.
• [ ] Get MVP string serialization and deserialization working #25
• [ ] Error PR?
• [ ] Fix all of the TODOs besides performance related TODOs
• [ ] Do any contributions.md stuff we want
• [ ] Reorganize the entire crate's structure (#29) (not necessarily required, but would be nice)
• [ ] Release 0.3.0

[AaronKutch]

I updated the checklist with everything I could think of. I have a week left before university starts again.

[Robbepop]

Thank you very much for this nice list! Many important points! However, I am a bit unsure if the time plannings of one week are a bit optimistic. ^^ After the 0.3 release we should form a github organization so that we both are equal owners of the crate. What do you think? Would provide you with more power and rights.

[AaronKutch]

I'll stay as co-author for now, and maybe reconsider after 0.3.0. Would it be possible for you to review a PR every week, only skipping a week occasionally whenever work is too hard or something? In the past there was periods of months between reviews, but I estimate that there will be ~20 PRs in between now and where I want 0.3.0 to be.

[Robbepop]

It mostly depends on the reviewability of the incoming PRs. If a PR is easy to review I will mostly do it right away. If it takes several hours on the other hand I am taking more time to start the review.

[AaronKutch]

This semester is by far the hardest semester I have ever had. I have had to work on weekends and even during this spring break to keep the school work from running me over. I think I am feeling some burn out right now. I still want to get one more PR in before end of semester stuff kicks in.

[AaronKutch]

Issue #42 is fixed now, lets keep that issue up a little longer in case we encounter a problem. I will do a PR for issue #41 to have BitWidth construction use TryFrom and other stuff. Then, I will have a PR to extract a new fuzz.rs using improved BitWidth ergonomics, testing, and feature flags. Then, you can get your GitHub Actions PR working.