"Bypassing" Specialization in Rust or How I Learned to Stop Worrying and Love F

https://news.ycombinator.com/rss Hits: 5
Summary

"Bypassing" specialization in Rust or How I Learned to Stop Worrying and Love Function Pointers I've spent nearly a year developing and refining my own FAT driver in Rust. For much of the last six months, I had to put the project on hold due to school commitments. However, I'm back now, especially since this project has become my most-starred repository on GitHub. During that journey, I (almost) learned how FAT and filesystems in general work behind-the-scenes and in my attempts to navigate the constraints imposed by the Rust programming language, I encountered what I thought was an immovable obstacle: specialization A quick word about specialization Specialization as a concept was introduced with RFC 1210 all the way back to 2015, long before I even had a serious passion about computers and programming. For our use case, specialization allows us to essentially override trait and struct impls. Let me demonstrate with an example: trait A {} trait B {} struct MyStruct<S>(S) where S: A; impl<S> MyStruct<S> where S: A { fn do_something(&self) { } } impl<S> MyStruct<S> where S: A + B { fn do_something(&self) { } } In Rust, the above code wouldn't compile, since we define the function do_something twice. With specialization, the compiler would realize that the second impl is more "specialized" than the first one and the above code would compile just fine. Then, if we constructed the struct MyStruct with its only field containing an object that implements trait A but not trait B, then we did the same but with an object that now implements both A and B, and called the do_something method on each one struct, the first do_something implementation and second do_something implementation would be run respectively. Cool, so why do the above code not compile? Well, I am not an expert in Rust soundness and safety, but according to the tracking issue (#31844) and some Zulip chats and Rust user forum threads I've found, there's a lifetime-related issue with the whole feature that no ...

First seen: 2025-07-20 03:31

Last seen: 2025-07-20 07:31