Skip to content

Instantly share code, notes, and snippets.

Proposal to loosen Maximally Minimal Specialization

This is intended to be a possible way of addressing one of the limitations of Maximally minimal specialization: always applicable impls.

I also want to simply mention Sound and ergonomic specialization for Rust as another proposal for solving a different problem with maximally minimal specialization, but my proposal is not related, and should be compatible therewith. I think it is still worth a read.

Please also note that I spent a long time researching and trying to learn as much as I can about the current state of specialization in rust, but there are many years of discussion regarding it, and I probably missed a lot. The above links point to articles that are already almost 4 years old, but they appear to be the most relevant discussions on getting specialization stabili

@vonZuben
vonZuben / specialization_and_hlist.md
Last active February 5, 2022 20:33
Specialization and Hlist

Specialization and Hlist

This is just for sharing an idea I had for an improved trait to get items from an hlist. There is a full code below you can try on stable rust today even without specialization, but it's pretty impractical without specialization due to very limited scalability.

For context an hlist (see the hlist or frunk crates) is a heterogeneous list, and you can retrieve items from it "by type" using an appropriate trait (Find and Selector). But the trait needs an index I in order to avoid overlapping trait implementations to work.

I want to be able to use the something like the Find and Selector traits, but without the index. Specifically, I have a use case where I want a public API with trait bo