Associated types are not correctly computed (at least not at the right time)

[paholg]

If I have an associated type that impls some trait or is some other known type, I can't treat it as so. Example (playpen link):

trait DoNothing {
    type Output;
}

struct Bob;
impl Bob {
    fn print() { println!("I AM BOB!"); }
}

impl DoNothing for Bob {
    type Output = Bob;
}

type BobAlso = <Bob as DoNothing>::Output;

fn main() {
    // works fine:
    Bob::print();
    // compiler error:
    BobAlso::print();
}

The type BobAlso is (or should be) just an alias for Bob, however when I try to call its print() function, the compiler complains that there is no print for <Bob as DoNothing>::Output without figuring out that that it is Bob.

[arielb1]

We don't normalize when expanding type aliases. We can't always normalize directly (because of late-bound regions) - maybe we should in to_ty?

cc @nikomatsakis

[nikomatsakis]

I had hoped (and still hope) to address these sorts of issues via lazy normalization. Sadly we haven't made much progress on that front yet.

[dylanede]

Here's another (simpler?) example that I believe exhibits the same bug:

trait Foo {
    type Out;
}

impl Foo for () {
    type Out = bool;
}

fn main() {
    type Bool = <() as Foo>::Out;
    let x: Bool = true; // Error E0308, mismatched types, expected <() as Foo>::Out
}

[dylanede]

@nikomatsakis, Has there been any progress on lazy normalization since your comment? Is there room for some mentored work on this? I've got experience with compilers and PL theory. I also wrote a C compiler in Rust for my final year project at university.

I have noticed that there seem to be a few gnarly issues in the type checker that don't seem to be making progress, often related to associated types. Is this due to limitations in the original design of the type checker's unification implementation? Would a redesign be of greater benefit in the long run?

[nikomatsakis]

This is mostly due to emphasis elsewhere. But there actually is
progress in this direction; in particular
#30533 introduces a major
refactoring that should (I think) make lazy normalization possible.
Now whether lazy normalization will work out as well as I hope remains
to be seen. If you'd be interested in pursuing that, I'm definitely
interested in mentoring! Perhaps we can discuss in IRC? Feel free to
privmsg me (nmatsakis) or e-mail me (same, but @mozilla.com).

On Thu, Jan 07, 2016 at 05:47:06AM -0800, Dylan Ede wrote:

@nikomatsakis, Has there been any progress on lazy normalization since your comment? Is there room for some mentored work on this? I've got experience with compilers and PL theory. I also wrote a C compiler in Rust for my final year project at university.

I have noticed that there seem to be a few gnarly issues in the type checker that don't seem to be making progress, often related to associated types. Is this due to limitations in the original design of the type checker's unification implementation? Would a redesign be of greater benefit in the long run?

---

Reply to this email directly or view it on GitHub:
#28828 (comment)