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.
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.