librustc: Implement associated types behind a feature gate.

[pcwalton]

This is waiting on an RFC, but this basic functionality should be
straightforward. The implementation essentially desugars during type
collection and AST type conversion time into the parameter scheme we
have now.

r? @nikomatsakis

(addendum by pnkfelix: the feature gate's name is associated_types)

[brendanzab]

Awesome!

Would it be that much harder to add associated statics?

[ptal]

This is great! I have tried to use it but faced some bugs.

• Internal compiler bug: http://is.gd/xiHkUe
• Trait inheritance: http://is.gd/GYdyCO
  • Note that it works if we don't inherit from Graph.

And finally just a remark, it is a bit cumbersome to prefix types that are declared in the trait with the current trait type, but maybe if it has some implications for the type-checking. If not, it could be cool to have the same shortcut for inherited associated types if there is no ambiguity.

All my tries has been done with this version of the compiler. It's not specified in the code snippets but I used #![feature(associated_types)].

[pcwalton]

Yes, associated statics will be a lot of work and this patch is already 5+ KLOC.

[pcwalton]

And finally just a remark, it is a bit cumbersome to prefix types that are declared in the trait with the current trait type, but maybe if it has some implications for the type-checking. If not, it could be cool to have the same shortcut for inherited associated types if there is no ambiguity.

There's no reason for it other than the fact that this is what the compiler already had support for. This patch is already huge so I'd like to implement that in a followup.

[pcwalton]

Internal compiler bug: http://is.gd/xiHkUe

Good catch. That should be an error (because you didn't have a generic type parameter), but instead it ICE'd.

You won't be able to do what you want until both this patch and #16432 land.

[brendanzab]

I guess associated statics are easier to add to APIs in a backwards compatible way than associated types. This is still awesome nonetheless - I am super excited about using this in gfx-rs and cgmath-rs.

[nmsmith]

This is awesome, I've been looking forward to associated types. I've also found need for associated statics/constants, so I hope to see that implemented in the future.

[pcwalton]

Updated with the syntax from the RFC. re-r? @nikomatsakis

[bluss]

Very exciting stuff. I'm testing the PR at yesterday's version (commit e797049fe )

Here are some bug reports already:

Inheriting has a bug:

pub trait Dimension {
   type IndexType;
}

// error: wrong number of type arguments: expected 1, found 0
// the error indicates the Dimension trait
pub trait RemoveAxis : Dimension { .. }

And <X as Trait>::InnerType can't be used in where clauses.

[pcwalton]

I'd like to do the where clause stuff in a followup since this patch is getting pretty big. (Also it may depend on trait reform.)

[japaric]

If you forget the associated type in an impl block, you get an ICE. Example:

#![feature(associated_types)]

trait Borrow {
    type Owned;

    fn borrow<'a>(&'a Borrow::Owned) -> &'a Self;
}

impl Borrow for int {
    //type Owned = int;

    fn borrow(_: &int) -> &int {
        unimplemented!();
    }
}

fn main() {}

Output:

ai.rs:9:6: 9:12 error: internal compiler error: ImplCtxt::associated_type_binding(): didn't find associated type
ai.rs:9 impl Borrow for int {

Version: This PR on top of 1dc3195

[nikomatsakis]

Reviewing latest push now (FYI)

[nikomatsakis]

OK, I more-or-less read through the PR and it all seems to make sense. I'm doing a local build to do some more local testing.

It's clear that the PR implements only a subset of what is described in the RFC (e.g., I don't believe that notation like T::U works, where T is a type; the scoping of associated types in a trait is different; you can't use associated types outside of generic fns; etc.). We should probably carefully enumerate the functionality of the RFC and plan out how we are going to bring it all in (and when!).

[nikomatsakis]

On the ride home, it occurred to me that some of the tests seemed to be in error. For example, I don't think it is intended that one can write (@aturon can confirm):

trait Foo {
    type T;
    fn get() -> Foo::T;
}

The problem is that Foo::T is basically saying "infer the self type" and there is no context with which to infer in a fn signature. Instead one ought to write T, Self::T or (maximally explicit) <Self as Foo>::T.

[aturon]

@nikomatsakis Yes, that's right: the RFC does not give any special treatment to the trait name in the body of the trait, so Foo::T is ambiguous there and elsewhere.

That said, the full resolution/matching rules still need to be laid out; you and I should sit down and write that up as an RFC soon.

(Interesting sidenote: under a possible HKT design, you could allow Foo::T as a kind of UFCS-style reference to a type, giving you back a type constructor. Of course that can be added later, if desired.)

[pcwalton]

@nikomatsakis Ambiguity (and, relatedly, scoping) rules addressed. re-r?

[bgamari]

@pcwalton I guess this doesn't cover bounds on associated types?

[pcwalton]

@bgamari No, it doesn't. I believe @nikomatsakis is working on generalized where clauses, which should make that more straightforward to implement.

[tedhorst]

Did you mean to revert jemalloc?

[pcwalton]

No, I'll fix that.