rust-variance

Compile three one-line probe functions that attempt to shorten and lengthen a lifetime through the type constructor, then read which ones compile. If only the shortening direction compiles the type is covariant, only the lengthening direction means contravariant, and rejection of both means invariant.

A struct becomes invariant when a field uses the parameter both covariantly and contravariantly, or contains interior mutability like Cell, RefCell, Mutex, or UnsafeCell. Mutable references and raw mutable pointers also force invariance in their type parameter.

The fn item type fixes its Output to &'static str, and trait bounds match by equality, so no coercion applies. Give the producer an unbounded output lifetime, wrap the call in a closure, or coerce it to a fn pointer which is covariant in the return type.

Yes, wrapping a field in Cell, RefCell, Mutex, or any UnsafeCell flips the struct from covariant to invariant, breaking downstream code that shortened lifetimes. Lock the intended variance with a private probe function or a compile_fail doctest run via cargo test --doc.

Sender is invariant because the channel stores and drops values of the message type, so allowing contravariance would let short-lived messages escape into a 'static context and be dropped after their borrows end. Write consumers as Sender<Message<'_>> and coerce at the send site instead.

PhantomData<fn(T)> makes a type contravariant in T, which is sound only for a type that never stores or drops a T. On a queue or channel handle that owns values, it is a soundness bug that Miri reports as a use-after-free; use PhantomData<T> instead.