Oh wow, that could be a very strong case for Rust's paradigm! I need some time to wrap my head around this, but I sincerely appreciate your help! I remember reading some of that tracking issue. It's been very interesting to learn about Rust thus far.
@dtolnay Would you ever consider putting some official-ish documentation out there in the rust-sphere? Hopefully it will be stable for documentation soon.
This system still uses linear specialization, it just adds a pattern of delegation that sort of makes it able to go horizontal instead of just vertical, if that makes sense. I'm a little confused by how to use it in my case, since it may prove to be too complicated as it scales beyond a diamond shape.
So it still uses the additive specialization, but you can kind of turn it on its side. (I'll explain with letters instead of Clone and Default)
You can get 0, A, B, or A +B.
Basically, he splits up A and B, and adds 1 constraint to each to get all 4 combinations.
So the specialization is like
0 and 0 + A.
B and B + A.
A + B
A + 0 B
So like red75prime said, that T is 0, the blanket statement, default, nothing, whatever you want to call it.
I've found that you can keep adding sideways constraints this way, or vertical constraints, but it creates an unusual hierarchy of possibilities that I haven't mapped out yet, but would most likely be unorthodox to reason with in practice. It seems it would have overlapping cases where it could go either vertical or horizontal. I haven't gotten very far with that yet, and have no idea what I'm doing.
I also have at least another idea in the works that I may be able to use to get specialization branching that also uses delegation. Still haven't worked on it yet.
(To my prior post: Now that I have tried it you can add the trait for if_not_clone() to the clause without throwing off code into branching.)
My reasoning seems to allow adding more traits. (Without going too far to complete expansion of example.)
I renamed the example trait to closer match option.
So going from the 2 (Clone+Default) to 3 (+Eq) seems like it would be adding 4 more traits. (If wanting full coverage.)
Going to 4 would take 8 more traits. To 5, 16 extra.
Those are not all the possibilities that you make with the way it is set up. Without changing anything, you can also set rules for like A + B + C and stuff like that, but I removed those in the example.
It seems like there may be a system that uses his technique that would work for branching if you could create two axes -- basically this just uses 1 axis -- there's one specialization that you keep adding 1 constraint to to get more possibilities.
The problem is, it seems you need 2 axes, 1 for children and 1 for siblings, but with this system I'm trying to squeeze 2 axes out of just 1. So by just wanting to add A + D, you also get things like A + C + D, but at the same time, not things like C + D. (or something like that)
So if I want to build a tree, it becomes quite complicated and unconventional, since you get weird combinations of what can inherit what, and letters can be either a sibling or a child, but you only have 1 axis to build from.
Still, his idea proves that sibling nodes are possible, so I think there's some intelligent way to scale a robust inheritance out of it -- I just don't know how to wrap my head around that right now.
This is for if you want to use composition, like generalizing events, (or if you don't - like in the example) but still want to be able to inherit from what you compose. Doing so with data is the other half of the battle and it's another story -- Rust really isn't designed for this, lol. Some notes on that in the link.