bitvec VS case-studies

I was also under the false impression that bitwise encoding was slow. When I first implemented bitcode with bitvec I got performance 20x worse than bincode. After writing my own implementation I was able to get much better performance.

interesting; i'll have to compare this to my rust counterpart. your numbers indicate some clever implementations i'd love to read

Not to mention having a lackluster std which causes you to use nonstardard not so well documented crates and a 40K LoC library to do "bit-twiddling" (the lib, https://github.com/bitvecto-rs/bitvec the blog that says "twiddle bits" https://blog.adamchalmers.com/making-a-dns-client/ and for crying out loud the blogger also used the language the author mentioned and I quote "ergonomics AND speed AND correctness")

https://github.com/bitvecto-rs/bitvec/issues/135 is a very funny read about how to perform inttoptr with provenance retention

Technically #135 gives me license to yank affected crates, but since the only exploit is "Miri crashes exactly one test out of the suite" it's not really worth it to be a stickler. Call it a truce

My friend Nika wrote a macro that packs a sequence of 1, 0, … tokens into a correctly structured bit-buffer, adaptable over any register type or bit-ordering, at compile time. It's now basically this whole file

if you are interested in a user manual, you can use mdbook as well. for an example, my bitvec project uses mdbook (book.toml) and a github action (.github/workflows/gh-pages.yml) to compile the guide and host it as a github pages website. it's slightly more complicated, and i'd like docs.rs to follow hexdoc.pm's example of hosting both api docs and prose, but until then this is a pretty reasonable solution.

the first one

i would browse the standard library, tower, nom, or my own bitvec to see layout and trait/record separation. in particular, std::io and std::net may be of use: io::Read and io::Write are pervasive examples of implementing unixy file-descriptor-like behavior in the type system

Luckily there is a workaround to emulate such a definition, which dtolnay discovered and explained here: https://github.com/dtolnay/case-studies/tree/b9802f6df8dc8e54970b83fb9af6df923b46abf5/unit-type-parameters.

I think they are talking about this one trick which the devs don't want you to know about. Note that while it looks like specialization, it works only in a few very limited cases and is quite fragile, so it's a hack, not a substitute for the real feature.

Also I suggest his case studies repo since you are looking at what is possible: https://github.com/dtolnay/case-studies

/u/dtolnay has a great case studies repository.

Once you have the basics down, read dtolnay's case studies. They show how to do advanced stuff with easy macros.

If you were writing your own println macro, you might be able to get away with this kind of hack: https://github.com/dtolnay/case-studies/blob/master/autoref-specialization/README.md

You can use "Autoref-based stable specialization" or use/mimic the impls crate.

With a subset of specialization likely riding the trains soon and a workaround available, why would you give up?

this works since values and types are in different namespaces (see: Rusts Universes or dtolnay's Case Study about "Unit struct with type parameters")

To do this with traits you would need specialization but since you are using macros you should be able to use "Autoref-based stable specialization". Here is a playground which uses the latter approach to implement the wanted macro without using any nightly features.