Pre-RFC: GAT variance

[Jules-Bertholet]

Explicit variance annotation has been discussed previously:

Associated type variance bounds

The problem Given a trait: trait Trait { type Assoc<'a, T, U>; } In the above, <Self as Trait>::Assoc<'a, T, U> is invariant with respect to Self, 'a, T, and U. Frustratingly, today's Rust provides no way to specify a different variance. This limits the language's expressiveness. For example, it makes it certain GAT abstractions much less ergonomic: It also makes it effectively impossible to implement generic data structures that store enum discriminants or pointer metadata, while pro…

Variance of lifetime arguments in GATs

I've been searching and couldn't find any previous discussion of this specific issue. GATs are great! I've been using them in one of my projects and they've been making huge improvements on some of my type-system woes. But I've ran into an annoying gotcha in the form of variance. I've made a GAT that generalizes over &'a T and std::cell::Ref<'a, T>. Both of those are covariant in their lifetime argument. But it seems like GATs are always invariant in their lifetime arguments. (Of course, if th…

Implementable trait aliases

With the stabilization of GATs, there has been some discussion on how some standard library traits, like Iterator and FnMut, could be backward-compatibly GATified. This recent blog post, for example. This is challenging because we can't break existing trait bounds. This post proposes a possible solution, that I haven't seen discussed anywhere before. Allow writing impl blocks for certain trait aliases, that only alias to a single trait plus some number of where clauses. For example, trait Fo…

Personally, I think covariance and contravariance should be treated like auto traits. For example, consider the following:

trait WithGat {
    type Gat<T>;
}

impl WithGat for () {
    type Gat<T> = Option<T>;
}

struct Foo<T: WithGat, U> {
    a: T,
    b: <T as WithGat>::Gat<U>,
}

Under current rules, the above is covariant in T and invariant in U, for any T and U. However, Foo<(), U> could potentially be inferred covariant in U—analogous to how auto-trait inference works today.

A more trait-bound like model of variance would give extra flexibility in other ways. For example, it would allow constraining variance only at the use-site:

#![feature(trait_alias)]
// Imagine that only some `MyDeref` impls can provide covariance

trait MyDerefCovariant = MyDeref
where
   for<'a> (<Self as  MyDeref>::Target<'a>: covariant_in<'a>);

fn foo<'a, T: MyDerefCovariant>(a: T::Target<'a>, b: T::Target<'a>) {}

fn bar<'a, 'b, T: MyDerefCovariant>(a: T::Target<'a>, b: T::Target<'b>) {
    foo::<T>(a, b)
}