Publishing my first crate: A general trait-forwarding crate (docs.rs)

submitted 8 months ago by Zistack to c/rust@programming.dev

3 comments fedilink hide all child comments

I'm building up to a new idiom for dealing with generic numeric types and traits, but this is the first step. I made it more general than I probably needed for my purposes, but it seemed like a good idea to just solve the whole problem given that I was going to do much of the work anyways.

Credit to the hereditary crate for inspiration on how to do it.

I'm very new at this software publishing thing, so lemme know if I messed something up.

top 3 comments

sorted by: hot top controversial new old

[-] BB_C@programming.dev 4 points 8 months ago* (last edited 8 months ago)

I wanted to mention that this reminds me of the old Delegation RFC, which some of us didn't like, exactly because it felt like a problem for proc-macros to solve. It eventually got postponed.

But then, the delegation terminology is used in hereditary, so you're probably aware of all that already ;)

Anyway, other crates like delegate, ambassador and portrait are mentioned in the latest comments below that RFC. I wanted to quickly check how many dependants each one of those have, but https://crates.io can't do that at the moment. Nice error message though!

Unfortunately, I have no time to check what kind of code each one of them crates generates, so I have nothing of value to add.

[-] Zistack 3 points 8 months ago

I was actually not aware of the RFC or those other crates. Ambassador and portrait seem kindof similar in their overall approach to how they accomplish things, though portrait appears to be solving a very different problem. My crate allows for forwarding based on conversions and not just delegation to members, which appears to be new (and this turns out to be important for my use-case.). It doesn't have anything for dealing with code that isn't in traits, but I wasn't intending to solve that problem.

I absolutely see why it would be nice to put delegation in at the language level. Most libraries aren't going to want to annotate their trait definitions just for this (std included), and having the compiler take care of things solves not only that, but also the annotation data format version issues that come with using proc-macros to do it.

It's a bit weird, though, because my conversion forwarding is actually strictly more powerful than delegation in some ways (but a little less flexible - mixing them grants the best of both techniques). Conversion forwarding allows for traits like FromIterator to be forwarded automatically for wrappers on containers, for example. You can't do that with delegates. It feels to me like you'd want both if you added either one of them in. The issue with trying to put something like conversion forwarding in is that the compiler either needs to know about the conversion traits (From, Into, AsRef, and AsRefMut)(As I write this, I realize I may have made a mistake in my crate... can guess what it is?) or it would need to be told how to do the conversions, complete with all additional generic parameters and trait bounds that would be required in the trait implementation. That's either violating some important abstraction boundaries in the language tools, or just extremely verbose.