Should bounds on mut trait objects be covariant?

[nrc]

Currently if Trait1 and Trait2 are traits, then &mut Trait1+Trait2 <: &mut Trait1. I.e., mutable trait objects are covariant. All other mutable references are invariant, that is &mut T <: &mut T' iff T /equiv T'.

Should trait objects also be invariant?

See also #12470, which is a similar issue but about lifetimes in the same situation (which must be invariant and not contravariant).

[pnkfelix]

cc me

[nikomatsakis]

cc me

[nikomatsakis]

Actually, I was thinking: if we were to permit multiple arbitrary traits (as I would eventually like to do) to occur in object expressions, then it is not clear that &mut A+B is a subtype of a &mut A (or &mut B)-- coercible, yes, but not a subtype. This is because the vtable will have to be swapped, since in the first case it must include methods for both A and B, and in the second only A (or B, respectively).

[nikomatsakis]

triage: P-backcompat-lang (1.0 beta)

[nikomatsakis]

Forgot about this little corner case. Hopefully now that #18737 is closed this should be easier to fix.

[nikomatsakis]

Let me elaborate my plan (which... so far ... seems to be working). Just removing the subtype relation alone breaks code because various bits of code rely on the ability to upcast the region bound (i.e., &mut (Foo+'a) <: &mut (Foo+'b) if 'a : 'b). However, while this is actually sound in the case of trait objects, it is not generally sound for &mut T, which is typically invariant w/r/t T. The only reason it's ok for trait objects is that we can't assign to the reference of the &mut in that case. In any case, to solve this, I've extended the upcast relation so that &mut (Foo+'a) -> &mut (Foo+'b) if 'a : 'b (where -> means "is coercible to).