[Solved] Variance of `dyn Trait + 'a`

[spunit262]

This is intentional behavior that was RFC'ed in 0599

Interaction with object coercion. The rules specify that &'a SomeTrait and &'a mut SomeTrait are expanded to &'a (SomeTrait+'a) and &'a mut (SomeTrait+'a) respecively. Today, in fn signatures, one would get the expansions &'a (SomeTrait+'b) and &'a mut (SomeTrait+'b) , respectively. In the case of a shared reference &'a SomeTrait , this difference is basically irrelevant, as the lifetime bound can always be approximated to be shorter when needed.

In the case a mutable reference &'a mut SomeTrait , however, using two lifetime variables is in principle a more general expansion. The reason has to do with "variance" -- specifically, because the proposed expansion places the 'a lifetime qualifier in the reference of a mutable reference, the compiler will be unable to allow 'a to be approximated with a shorter lifetime. You may have experienced this if you have types like &'a mut &'a mut Foo ; the compiler is also forced to be conservative about the lifetime 'a in that scenario.

However, in the specific case of object types, this concern is ameliorated by the existing object coercions. These coercions permit &'a mut (SomeTrait+'a) to be coerced to &'b mut (SomeTrait+'c) where 'a : 'b and 'a : 'c . The reason that this is legal is because unsized types (like object types) cannot be assigned, thus sidestepping the variance concerns. This means that programs like the following compile successfully (though you will find that you get errors if you replace the object type (Counter+'a) with the underlying type &'a mut u32 ):