Trait objects, auto trait subtyping?

[mathstuf]

@steffahn

If there's such a big difference, you certainly could demonstrate some piece of code that shows how the fact that dyn for<'a> Tr<'a> is a subtype of dyn Tr<'static> makes any difference (e. g. in terms of what code compiles and/or doesn't compile), compared to what would happen if it just gives rise to a set of allowed coercions , right? I haven't been able to make out any effects of a special treatment of dyn for<'a> Tr<'a> and dyn Tr<'static> in type inference myself, I'm really interested in learning more.

I can't say I'm all that sure if whether it's relevant or not, but the GhostCell API uses impl for<'a> FnOnce(…) -> R and I don't think 'static works there.

But I admit that I'm not confident that I'm following the logic here properly and may not actually be relevant; it just reminds me of that.

[steffahn]

Note that the third example can also fail to compile when we use a pair of types where one is a subtype of another.

trait Foo<'a> {}

fn foo1() -> &'static dyn for<'a> Foo<'a> {
    todo!();
}

fn foo2() -> &'static dyn Foo<'static> {
    todo!();
}

fn main () {
    let mut f;
    f = foo1();
    f = foo2();
}

(and the other 2 examples' main functions do compile with these foo1/foo2 above)

---

Maybe the claim "Subtyping [...] can occur at any stage in type checking or inference." just promises more than what the compiler actually offers?

[steffahn]

@mathstuf

But I admit that I'm not confident that I'm following the logic here properly and may not actually be relevant; it just reminds me of that.

It's not really relevant. I'm not claiming that there's no difference between the types dyn for<'a> Tr<'a> and dyn Tr<'static>, there definitely is! I'm saying that the relationship between those two types might be fully described by a set of coercion rules and without additional/alternative "magic" in type-checking and/or type-inference.

[SkiFire13]

@mathstuf

I can't say I'm all that sure if whether it's relevant or not, but the GhostCell API uses impl for<'a> FnOnce(…) -> R and I don't think 'static works there.

This is because you're trying to use a supertype in place of a subtype, but this is not guaranteed to work (the opposite it possible though). To make a simplier example without lifetimes, it's as if you're saying that a function that requires T: Ord can't be changed to use T: PartialOrd, but the opposite is possible because Ord implies PartialOrd.