#unconstrainted type when implementing From trait

9 messages · Page 1 of 1 (latest)

azure holly
#

hey all.

I have an object trait that lets me box up structure that implement related but non interacting traits.
That object traits let me take boxed dyn traits (which themselves implement object) and call an as_<trait>() -> Option<&'a dyn <trait>> function to get references

now I have some other structs that I want to create from one of these references

pub type StructureRef<'a, T: Object> = &'a dyn Structure<ID = <T as Object>::ID>;

// ...
impl<'a, T: Object> From<StructureRef<'a, T>> for StructureInfo {
    fn from(value: StructureRef<'a, T>) -> Self {
        // ...
    }
}

however rustc complains with

the type parameter `T` is not constrained by the impl trait, self type, or predicates
unconstrained type parameter 

but I can't figure out how this could be true. how could T be unconstrained?
is StructureRef<'a, T> not district for every T? meaning From<StructureRef<'a T>> should be too?

hearty field
#

you could have two different Object implementations whose ID associated types are the same, so StructureRef is not distinct for every T.

azure holly
#

well shoot.

hearty field
#

if you can arrange so that trait Structure has an Object associated type instead of an ID associated type then that would fix it

azure holly
#

the ID assoceated type actualy is Object's assoceated type, because Structure impliments Object

#

the idea is that I can jump to any other trait interface implemented by that object

#

is there perhaps a better way to declare the Ref type to get around this?

#

hmm. perhaps I should just get rid of the associated type all together and just use an alias

#

is was mostly there incase I wanted to switch Id types not so two different ID types could exist at the same time.