Transitive traits

help
21

Ahh, ok. So you're trying to do something analogous to testing if (x: u8) == (y: u64) but without having to perform the conversion? And in your case you're doing it on traits instead of ints...

In the u8 vs u64 instance it can be done by checking that all u64 bits are zero except the smallest 8 which should equal the 8 bits of x.

But that kind of methodology would need to be hand developed based on YOUR understanding of how to check A vs C. The compiler knowing that C can become B, which can become A doesn't give it the knowledge of how to compare A and C.

But... A is a subset of B which is a subset of C implies:
A has all parts from B (in some form), but B may have more, and
B has all parts from C (in some form), but C may have more, thus
A has all parts from C (in some form), but C may have more...

So, could you use something like partial default to pull the unneeded parts of C away and just compare the functional bits of C which can be directly compared to A? Or are there too many operations on the conversion of C->B->A?

1 Like
22

I guess my ultimate solution is a slight variant of this approach. I added a second field accessor to the trait that A, B, and C all share that returns None instead of a compile error when trying to get a missing field, and a set of unchecked operations that use those and panic if they ever see a None.

So now I have two parallel sets of methods: one that won’t compile if you do something wrong and another that will compile but panic unconditionally. This lets me do the things that I know are legitimate but can’t convince the compiler of, after they’ve been protected by appropriate type bounds.

23

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.