@Andrew15-5 is there a reason this hasn't been merged in yet? Is this project unmaintained?

My guess is that the author is very busy, which is, of course, unfortunate, but understandable. This does kind of fall under the definition of unmaintained project.

This is the last message I've seen: #35 (comment).

I want to say that after reworking the recent changes to fix the merge conflicts (and during the initial development of the PR) I faced a lot of issues, due to poor architecture (it's not that bad, but it's not that great either). The #35 and #25 (comment) do have a point, that the code base can be improved to be more readable and maintainable.

In particular, I don't like the copied tests from Rust file to Markdown file: you have to keep them in sync, and I haven't found any copy/sync logic in the justfile. It's super easy to mess up the tests in the Markdown file, as they will become either invalid or simply outdated. There are a lot of boilerplates (including a lot of booleans), such as:

The LN_KIB/LN_KB turned out not being accurate enough that some tests just failed because of the accuracy. So moving away from logarithms and exponents (like in #35) will be a better choice, IMO.

There are units bigger than PB/PiB, so adding them for completeness would be great.

For tests, it's kinda unfortunate that you can't do a simple wrapper that won't affect the place where the panic is happened (at least I don't know of that one, probably can edit the built-in macros). So when one of the tests that call

https://github.com/hyunsik/bytesize/blob/5de80fbac0648df8d1bb10fa098f1fad45ef358c/src/lib.rs?plain=1#L449-L451

fails, it will show the line where the assert_eq!() is called (inside assert_to_string), and not where the test is defined. This (can) significantly slows down the debugging process.

In conclusion, there are various things that need improvement and I can offer help in rewriting some of the stuff in the code base, but considering I don't have enough free time right now, the offer is for the future.