New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement inherent associated items (see RFC 59). #8995

Open
pnkfelix opened this Issue Sep 5, 2013 · 15 comments

Comments

Projects
None yet
10 participants
@pnkfelix
Member

pnkfelix commented Sep 5, 2013

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

@cmr

This comment has been minimized.

Member

cmr commented Dec 30, 2013

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

@cmr

This comment has been minimized.

Member

cmr commented Dec 30, 2013

(type aliases would need to preceed all methods)

@pnkfelix

This comment has been minimized.

Member

pnkfelix commented Dec 31, 2013

@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?

@cmr

This comment has been minimized.

Member

cmr commented Dec 31, 2013

@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

This comment has been minimized.

Member

huonw commented Dec 31, 2013

Why is that less crazy than

fn foo() { bar() }

fn bar() {}

?

@cmr

This comment has been minimized.

Member

cmr commented Dec 31, 2013

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

This comment has been minimized.

Member

pnkfelix commented Jan 9, 2014

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

@reem

This comment has been minimized.

Contributor

reem commented Sep 15, 2014

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

@pnkfelix

This comment has been minimized.

Member

pnkfelix commented Oct 6, 2014

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

This comment has been minimized.

Member

pnkfelix commented Oct 6, 2014

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

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

@pnkfelix pnkfelix changed the title from RFC: allow type definition item within impl to implement inherent associated items (see RFC 59). Oct 6, 2014

@rohel01

This comment has been minimized.

rohel01 commented Aug 14, 2015

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

    }
}
@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Feb 7, 2017

I'm going to tag this with the tags from #8995 since it was closed without this being implemented.

@yodaldevoid

This comment has been minimized.

Contributor

yodaldevoid commented Jan 8, 2018

@steveklabnik I think you meant to reference #17307 rather than #8995, which is this issue.

@tinaun

This comment has been minimized.

Contributor

tinaun commented Jan 22, 2018

note that inherent associated consts work perfectly fine today

#[derive(Debug)]
struct Vector {
    x: f32,
    y: f32,
    z: f32,
}

impl Vector {
    const ZERO: Self = Vector { x: 0.0, y: 0.0, z: 0.0 };
    
    fn new(x: f32, y: f32, z: f32) -> Self {
        Vector {
            x, y, z
        }
    }
}
@eddyb

This comment has been minimized.

Member

eddyb commented Aug 20, 2018

@nikomatsakis Is it right to assume that this can't be implemented without lazy normalization?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment