Tracking issue for inherent associated types

[pnkfelix]

This is a tracking issue for the "inherent associate type" part of "inherent associated items" part of the RFC 195 "associated items"

Original description for historic preservation

When developing a type-parametric impl, I found myself writing code somewhat like this:

    struct Grammar<T, NT> { ... }

    impl<T:Clone,NT:Eq+Hash+Clone+Primable> Grammar<T,NT> {
        fn to_nt_map(&self) -> HashMap<NT, ~[Prod<T,NT>]>
        {
            type Rules = ~[Prod<T,NT>];
            type NTMap = HashMap<NT, Rules>;        
          ...
        }

        fn from_nt_map(start: &NT, rules: &HashMap<NT, ~[Prod<T,NT>]>)
            -> Grammar<T,NT>
        {
            type Rules = ~[Prod<T,NT>];
            type NTMap = HashMap<NT, Rules>;
          ...
        }

        pub fn eliminate_left_recursion(&self) -> Grammar<T,NT>
        {
          ...
        }

        ...

    }

I cannot make a type definition for HashMap<NT, ~[Prod<T,NT>]> outside of the impl because it then those free references to NT and T would be unbound.

And I cannot put a type definition within the impl, even an impl for a struct such as this (it simply does not parse with the current grammar).

(Being able to put type definitions within impls will probably arise naturally from #5033, when we get around to that. But that is nonetheless a separate issue from this: Associated Types (and Associated Items) are about enabling certain patterns for the user of a trait, while this ticket describes a convenience for the implementor of a struct.)

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

None

Implementation history

• Add incomplete feature gate for inherent associate types. #82516
• Correctly resolve Inherent Associated Types #103621
• Respect visibility & stability of inherent associated types #104348
• Properly substitute inherent associated types. #105224
• Normalize inherent associated types after substitution #105315
• Detect inherent associated types not having CamelCase #105768
• Type-directed probing for inherent associated types #105961
• Introduce AliasKind::Inherent for inherent associated types #109410
• rustdoc: render visibility on associated types #110945
• Pretty-print inherent projections correctly #111486
• Structurally normalize weak and inherent in new solver #114594
• Do not erase late bound regions when selecting inherent associated types #118118
• Relate Inherent Associated Types using eq #118262
• Don't build ParamEnv and do trait solving in ItemCtxts when lowering IATs #140247

[emberian]

Nominating; is backwards compatible. I can try and take this on if we decide we want it.

[emberian]

(type aliases would need to preceed all methods)

[pnkfelix]

@cmr said "(type aliases would need to preceed all methods)"

why? To my knowledge there is no such ordering constraint for type aliases within a mod item, so why would an impl item require this?

[emberian]

@pnkfelix yikes, you're right. I think they should be. Why? Because:

#[crate_type="lib"];

mod bar {
    fn foo() -> T {
        32i
    }
    type T = int;
}

is crazy.

[huonw]

Why is that less crazy than

fn foo() { bar() }

fn bar() {}

?

[emberian]

I cede.

On Tue, Dec 31, 2013 at 1:05 AM, Huon Wilson notifications@github.comwrote:

Why is that less crazy than

fn foo() { bar() }
fn bar() {}

?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8995#issuecomment-31385141
.

[pnkfelix]

assigning P-low priority (is backwards compatible going foward, as cmr said).

[reem]

Triage: How does this interact with Associated Types? At least a new syntax would probably have to be chosen.

[pnkfelix]

I think that this feature request is actually satisfied by the Associated Items RFC.

In particular, the section "inherent associated items" of RFC 59 implies (to me) that you can write the exact example that I had asked for.

(I did write in the issue description that this feature request is distinct from associated types, but nonetheless, it seems that the author of RFC 59 decided that it was a natural feature to include.)

[pnkfelix]

So, this now seems to be a subissue of #17307.

I will change the title to "implement inherent associated items."

[rohel01]

Hello, I hope this the right place to ask for my request.

Associated types currently only work with traits.
I think they are also useful for structs. Is there a reason for the current limitation ?

pub struct GenericStruct<A, B> {
    fa : A,
    fb : B,
}

struct GenericResult<A, B> {
    fa : A,
    fb : B,
}

impl <A, B> GenericStruct<A, B> {


    // I d like to write
    // type Result = Option<GenericResult<A, B>>;
    // and use it in the code

    fn new(a: A, b : B) -> Option<GenericResult<A, B>> {
        Some(GenericResult {fa: a, fb : b})

    }
}