Parse and accept type equality constraints in where clauses

[jroesch]

Implement the missing type equality constraint specified in RFC 135.

Examples

fn sum<I: Iterator>(_: I) -> i32
where
    I::Item == i32 // or `I::Item = i32`
{
    // ...    
}

[sgrif]

I don't think associated type bindings are quite the same as this, since they aren't taken into account for determining overlapping impls (which appears to have been intentional) http://is.gd/em2JNT

[cramertj]

@sgrif Doesn't that make this a kind of duplicate of rust-lang/rfcs#1672?

Edit: obviously with semantic differences, but I believe they allow for expressing the same types of bounds.

[tupshin]

I just ran into this limitation pretty hard while trying to do type level operations on HLists. Any work planned?

The only possible workaround I see is this bitrotted brilliant abomination
https://github.com/freebroccolo/unify.rs

[dhardy]

Show question (answered below)

Taking this idea further (`where` on associated types), I want to do the following:

/// Helper trait for creating implementations of `RangeImpl`.
pub trait SampleRange: PartialOrd {
    type T: RangeImpl where T::X == Self;
}

/// Helper trait handling actual range sampling.
pub trait RangeImpl {
    /// The type sampled by this implementation.
    type X: PartialOrd;
    
    /// Construct self.
    /// 
    /// This should not be called directly. `Range::new` asserts that
    /// `low < high` before calling this.
    fn new(low: Self::X, high: Self::X) -> Self;
    
    /// Sample a value.
    fn sample<R: Rng+?Sized>(&self, rng: &mut R) -> Self::X;
}

The latter trait on its own does all the work. The first one is just there to make the following work without explicitly specifying the type implementing RangeImpl.

#[derive(Clone, Copy, Debug)]
pub struct Range<T: RangeImpl> {
    inner: T,
}

pub fn range<X: SampleRange, R: Rng+?Sized>(low: X, high: X, rng: &mut R) -> X {
    assert!(low < high, "distributions::range called with low >= high");
    Range { inner: X::T::new(low, high) }.sample(rng)
}

[sgrif]

@dhardy What you want is just type T: RangeImpl<X = Self>;

[dhardy]

@sgrif that actually works, thanks!

[golddranks]

I would very much like to see this happen. Writing highly generic code is a pain, if you can't rename associated types inside traits, and this helps to do it, by asserting that a simple associated type is the same type as some monstrous thing: type TableQuery and where Self::TableQuery == <<Self::DbTable as HasTable>::Table as AsQuery>::Query.

[pnkfelix]

@rustbot label +T-lang +I-lang-nominated +S-tracking-design-concerns +S-tracking-unimplemented

(@jackh726 says that niko has had some concerns regarding arbitrary where clause equality constraints.)

[nikomatsakis]

We discussed this in the lang-team meeting today. I am indeed concerned about general T = U constraints, for the reasons expressed in the minutes, but we were thinking that perhaps we could accept a more limited form of where T::Item = U or <T as Iterator>::Item = U, which would be equivalent to today's T: Iterator<Item = U>... thoughts?

[jackh726]

Accepting where T::Item = U I think is pretty easy and should only require changes at the ast and hir levels. Once astconv is called, we store a ProjectionPredicate for that.

[LegionMammal978]

When was it decided to use single = instead of double == for these constraints? I'd strongly prefer the latter. With where T: Iterator<Item = U>, I see that T is an Iterator, with its Item type assigned to U, not unlike the syntax for default type parameters. And with where <T as Iterator>::Item == U, I see that we are imposing a boolean predicate on the two types. But with where <T as Iterator>::Item = U, we seem to assign a type to the projection, which seems as odd to me as assigning f() = 123.

To me, it ultimately comes down to the symmetry of the operator. <T as Iterator>::Item == U is equivalent to U == <T as Iterator>::Item, and this is clarified by the equality syntax. Conversely, T: Iterator<Item = U> is not equivalent to T: Iterator<U = Item>, and this is clarified by the assignment syntax. This indication of symmetry would be especially useful in bounds such as <T as Foo>::Assoc == <T as Bar>::Assoc, where currently we must write an unwieldy T: Foo<Assoc = <T as Bar>::Assoc>. So why should we use a single = in these top-level bounds?

[ireina7]

A working demo of simple type equality bounds in stable Rust:

Rust Playground

use std::marker::PhantomData;

trait TyEq {}

impl<T> TyEq for (T, T) {}

fn require_ty_eq<A, B>() where (A, B): TyEq {}

struct Z;
struct S<N>(PhantomData<N>);

fn compiles() {
    require_ty_eq::<Z, Z>();
    require_ty_eq::<S<Z>, S<Z>>();
}

fn does_not_compile() {
    require_ty_eq::<S<Z>, S<S<Z>>>();
}

@scottjmaddox But this constraint only works on Sized types? any idea to relax this?

[Jules-Bertholet]

But this constraint only works on Sized types? any idea to relax this?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=40979a4328a4157253dbf78f501e213c

[dhardy]

The TyEq "working demo" doesn't really work though:

#![allow(unused)]

trait TyEq {}

impl<T: ?Sized> TyEq for (*const T, *const T) {}

fn convert<In, Out>(x: In) -> Out
where
    (*const In, *const Out): TyEq,
{
    // error[E0308]: mismatched types
    x
}

---

Most of the time, working around the lack of type equality constraint isn't too hard, but in more complicated cases it's still a problem:

struct Something<F: Foo>(F);
impl<F: Foo> Something {
    fn new<B>(b: B) -> Self
    where
        Wrap<B> == F,
    {
        Something(Wrap(b))
    }
}

The only recourse here seems to be to pass in Wrap<B> instead of B.

[Windabove]

A simple workaround

trait TyEq<T> {
    fn rw(self) -> T;
    fn rwi(x: T) -> Self;
}

impl<T> TyEq<T> for T {
    fn rw(self) -> T {
        self
    }
    fn rwi(x: T) -> Self {
        x
    }
}

fn f<T, U>(x: T) -> U where T: TyEq<U> { // ... where T == U
    x.rw()
}

fn g<T, U>(x: T) -> U where U: TyEq<T> { // ... where U == T
    U::rwi(x)
}

[lierdakil]

Most of the time, working around the lack of type equality constraint isn't too hard, but in more complicated cases it's still a problem

Actually, isn't as much of a problem, at least in the example posed. Here's a full example:

trait TyEq
where
    Self: From<Self::Type> + Into<Self::Type>,
    Self::Type: From<Self> + Into<Self>,
{
    type Type;
}

impl<T> TyEq for T {
    type Type = T;
}

struct Wrap<B>(B);

trait Foo {}
struct Something<F: Foo>(F);
impl<F: Foo> Something<F> {
    fn new<B>(b: B) -> Self
    where
        Wrap<B>: TyEq<Type = F>, // or F: TyEq<Type = Wrap<B>>, or both
    {
        Something(Wrap(b).into())
    }
}

One quirk of this approach is that it's not commutative. So F: TyEq<Type = Wrap<B>> by itself does not imply Wrap<B>: TyEq<Type = F> and vice versa (it has to hold, the compiler just has no idea). Which isn't a bad thing necessarily, and can be exploited for fun and profit (mandatory visible type applications, anyone?).

Another quirk in this particular implementation is that all types have to be Sized. Which is not that terrible of a limitation, but can be slightly annoying to deal with.

Not at all surprising at the end of the day, but not something you'd necessarily expect from a true equality constraint either.