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)
}