Multiple GAT constraints with different generics on trait bounds

language design
1

Currently, this code doesn't compile:

trait Target {}
trait Base { type Target<T>; }

trait Derived1: Base<Target<u32> = u32, Target<u64> = u64> {}
// error[E0719]: the value of the associated type
// `Target` in trait `Base` is already specified

trait Derived2: Base<Target<u32>: Target, Target<u64>: Target> {}
// error[E0719] as well

However, without such a feature, equivalents like Derived1 would be impossible(see the reply below), while users requiring equivalents like Derived2 would write a bunch of where clauses that are needed at every reference site alongside the trait itself:

trait Target {}
trait Base { type Target<T>; }
trait Derived2: Base
where
    Self::Target<u32>: Target,
    Self::Target<u64>: Target,
{}

fn test<T: Derived2>(_: T)
where
    T::Target<u32>: Target, // Removing those where clauses
    T::Target<u64>: Target, // would result in a compile error.
{}

IMHO, besides the obvious verbosity, it could be viewed as a kind of unintended abstraction leakage (for example, library implementors would want to hide a private Target & Base trait with a public Derived2 trait).

Supporting multiple GAT constraints with different generics on trait bounds can eliminate all the issues mentioned above and enable users with a more powerful type system.

4 Likes
2

Issue filed: E0719 false positive with GATs · Issue #143143 · rust-lang/rust · GitHub

3 Likes
3

As a sort of workaround that may or may not be applicable in your use case, you can add a dummy type variable to the subtraits to parameterize over Base::Target<_>:

trait Target { fn foo(); }
trait Base { type Target<T>; }

trait Derived1<T>: Base<Target<T> = T> {}

trait Derived2<T>: Base<Target<T>: Target> {}

fn test1<U, T: Derived1<u32>>(_: T) {
    let b: <T as Base>::Target<u32> = 42;
}

fn test2<U, T: Derived2<U>>(_: T) {
    T::Target::foo();
}

Those universal bounds should (I think) be strictly equivalent to the OP bounds special cased for u32 and u64, as long as we don't have specialization of GATs, anyway. The dummy type variables wouldn't be needed if we had HRTBs for types ie. for<T> Target<T> = T.

1 Like
4

Wow, I didn't think of that. What a smart idea!

For now, I can merge multiple GAT bounds into one place by defining "middleware" traits with generics:

trait Target { fn foo(); }
trait Base { type Target<T>; }

trait Fixed<T>: Base<Target<T> = T> {}
trait Bounded<T>: Base<Target<T>: Target> {}

trait Derived1: Fixed<u32> + Fixed<u64> {}
trait Derived2: Bounded<u32> + Bounded<u64> {}


fn test1<T: Derived1>(_: T) {
    let b1: T::Target<u32> = 42u32;
    let b2: T::Target<u64> = 42u64;
}

fn test2<T: Derived2>(_: T) {
    T::Target::<u32>::foo();
    T::Target::<u64>::foo();
}

Although it still adds some verbosity, it solves the issue as expected. Thanks for your suggestion!

5

FWIW if you use the

trick, you can have this Just Work :tm::

trait Target {}
trait Base { type Target<T>; }
#[::implied_bounds::implied_bounds]
trait Derived2: Base
where
    Self::Target<u32>: Target,
    Self::Target<u64>: Target,
{}

fn test<T: Derived2>(_: T)
where
    /* nothing */
{} // OK!

It involves a simpler, and perfectly general, design than your Bounded<T> thing, but it's quite similar nonetheless :slightly_smiling_face: