Skip to content
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

Tracking issue for inherent associated types #8995

Open
3 tasks
pnkfelix opened this issue Sep 5, 2013 · 32 comments
Open
3 tasks

Tracking issue for inherent associated types #8995

pnkfelix opened this issue Sep 5, 2013 · 32 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-inherent_associated_types `#![feature(inherent_associated_types)]` S-tracking-impl-incomplete Status: The implementation is incomplete. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Sep 5, 2013

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

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.

Original description

(This code is written in ancient version of Rust, and is not meant to be used directly.)

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

Steps

Unresolved Questions

Implementation history

@emberian
Copy link
Member

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

@emberian

This comment has been minimized.

@pnkfelix

This comment has been minimized.

@emberian

This comment has been minimized.

@huonw

This comment has been minimized.

@emberian

This comment has been minimized.

@pnkfelix
Copy link
Member Author

pnkfelix commented Jan 9, 2014

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

@reem
Copy link
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
Copy link
Member Author

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
Copy link
Member Author

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 RFC: allow type definition item within impl implement inherent associated items (see RFC 59). Oct 6, 2014
@rohel01
Copy link

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 steveklabnik added A-associated-items Area: Associated items (types, constants & functions) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. and removed A-grammar Area: The grammar of Rust A-typesystem Area: The type system P-low Low priority labels Feb 7, 2017
@steveklabnik
Copy link
Member

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

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 19, 2017
@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 27, 2017
@yodaldevoid
Copy link
Contributor

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

@tinaun
Copy link
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
Copy link
Member

eddyb commented Aug 20, 2018

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

@peku33
Copy link

peku33 commented Feb 26, 2023

Were there any changes made to this in one of last releases?

struct Foo {
    bar: Self::Bar,
}
impl Foo {
    pub type Bar = usize;
}

used to work a couple of nightly releases ago.

Now it fails to compile with error:

error[E0391]: cycle detected when computing predicates of `Foo`
  --> src\main.rs:5:1
   |
5  | struct Foo {
   | ^^^^^^^^^^
   |
note: ...which requires computing predicates of `Foo`...
  --> src\main.rs:5:1
   |
5  | struct Foo {
   | ^^^^^^^^^^
note: ...which requires computing inferred outlives predicates of `Foo`...
  --> src\main.rs:5:1
   |
5  | struct Foo {
   | ^^^^^^^^^^
   = note: ...which requires computing the inferred outlives predicates for items in this crate...
note: ...which requires computing type of `Foo::bar`...
  --> src\main.rs:6:5
   |
6  |     bar: Self::Bar,
   |     ^^^^^^^^^^^^^^
note: ...which requires computing normalized predicates of `Foo`...
  --> src\main.rs:5:1
   |
5  | struct Foo {
   | ^^^^^^^^^^
   = note: ...which again requires computing predicates of `Foo`, completing the cycle
note: cycle used when collecting item types in top-level module

@flouet-company
Copy link

I am just curious about the status of this issue. Is someone working on this or has someone made any progress in this space?

@fmease
Copy link
Member

fmease commented Feb 26, 2023

There's been a recent series of PRs that work towards fully implementing inherent associated types by @fee1-dead, @cjgillot and me.

I highly suspect that the last one on that list (#105961) broke the code posted above. @peku33, could you please open an issue for the cycle error and tag me? Thanks. Note however that inherent_associated_types is still an incomplete feature and thus it's likely to break every so often.

Is someone working on this or has someone made any progress in this space?

@flouet-company, I'm assigned to several issues related to IATs and I'm in close contact with some members of T-types in order to properly implement inherent associated types.

@jhpratt
Copy link
Member

jhpratt commented Feb 26, 2023

I'd just like to say thank you to you three for working on this feature! I know it's not simple, but it's something a lot of people will appreciate when it's eventually completed.

github-actions bot pushed a commit to rust-lang/glacier that referenced this issue Mar 24, 2023
=== stdout ===
=== stderr ===
error[E0261]: use of undeclared lifetime name `'d`
  --> /home/runner/work/glacier/glacier/ices/109299.rs:10:21
   |
10 | impl<'cursor> Lexer<'d> {
   |      -              ^^ undeclared lifetime
   |      |
   |      help: consider introducing lifetime `'d` here: `'d,`

error[E0412]: cannot find type `DocCursorImpl` in this scope
  --> /home/runner/work/glacier/glacier/ices/109299.rs:11:23
   |
11 |     type Cursor<'a> = DocCursorImpl<'a>;
   |                       ^^^^^^^^^^^^^ not found in this scope

error[E0658]: inherent associated types are unstable
  --> /home/runner/work/glacier/glacier/ices/109299.rs:11:5
   |
11 |     type Cursor<'a> = DocCursorImpl<'a>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: see issue #8995 <rust-lang/rust#8995> for more information
   = help: add `#![feature(inherent_associated_types)]` to the crate attributes to enable

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0261, E0412, E0658.
For more information about an error, try `rustc --explain E0261`.
==============
github-actions bot pushed a commit to rust-lang/glacier that referenced this issue May 9, 2023
=== stdout ===
=== stderr ===
error[E0637]: `&` without an explicit lifetime name cannot be used here
 --> /home/runner/work/glacier/glacier/ices/109071.rs:4:17
  |
4 |     type Item = &[T];
  |                 ^ explicit lifetime name needed here

error[E0601]: `main` function not found in crate `109071`
  --> /home/runner/work/glacier/glacier/ices/109071.rs:11:2
   |
11 | }
   |  ^ consider adding a `main` function to `/home/runner/work/glacier/glacier/ices/109071.rs`

error[E0107]: missing generics for struct `Windows`
 --> /home/runner/work/glacier/glacier/ices/109071.rs:3:9
  |
3 | impl<T> Windows {
  |         ^^^^^^^ expected 1 generic argument
  |
note: struct defined here, with 1 generic parameter: `T`
 --> /home/runner/work/glacier/glacier/ices/109071.rs:1:8
  |
1 | struct Windows<T> {}
  |        ^^^^^^^ -
help: add missing generic argument
  |
3 | impl<T> Windows<T> {
  |                +++

error[E0658]: inherent associated types are unstable
 --> /home/runner/work/glacier/glacier/ices/109071.rs:4:5
  |
4 |     type Item = &[T];
  |     ^^^^^^^^^^^^^^^^^
  |
  = note: see issue #8995 <rust-lang/rust#8995> for more information
  = help: add `#![feature(inherent_associated_types)]` to the crate attributes to enable

error: aborting due to 4 previous errors

Some errors have detailed explanations: E0107, E0601, E0637, E0658.
For more information about an error, try `rustc --explain E0107`.
==============
github-actions bot pushed a commit to rust-lang/glacier that referenced this issue May 9, 2023
=== stdout ===
=== stderr ===
warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes
 --> /home/runner/work/glacier/glacier/ices/109790.rs:1:12
  |
1 | #![feature(inherent_associated_types)]
  |            ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: see issue #8995 <rust-lang/rust#8995> for more information
  = note: `#[warn(incomplete_features)]` on by default

warning: struct `Foo` is never constructed
 --> /home/runner/work/glacier/glacier/ices/109790.rs:3:8
  |
3 | struct Foo<T>(T);
  |        ^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: associated type `Assoc` is never used
 --> /home/runner/work/glacier/glacier/ices/109790.rs:6:10
  |
5 | impl<'a> Foo<fn(&'a ())> {
  | ------------------------ associated type in this implementation
6 |     type Assoc = &'a ();
  |          ^^^^^

warning: function `bar` is never used
  --> /home/runner/work/glacier/glacier/ices/109790.rs:12:4
   |
12 | fn bar(_: for<'a> fn(Foo<fn(&'a ())>::Assoc)) {}
   |    ^^^

warning: 4 warnings emitted

==============
@Cypher1
Copy link

Cypher1 commented May 30, 2023

This seems particularly important for resolving 'clippy::type_complexity' when using large types inside parameterized types with multiple arguments.

Normally we'd use a type Foo = Bar<A, B, C>; but in a generic type, those types may not be accessible except via more type parameters, leading to new complex types.

Keep to hear more about blockers :)

@fmease
Copy link
Member

fmease commented May 30, 2023

Keep to hear more about blockers

The most recent major blocker is fixing #108491 which is not easy it seems. Basically, you cannot use inherent associated types inside of structs, enums, unions or where clauses (as opposed to function bodies, constants and type aliases) and some function signatures without encountering a cycle error first. According to my current understanding this is due to architectural limitations in the compiler (see this semi-related Zulip topic, cc #22519 the equivalent for trait assoc tys).

Since #109410 got merged, I'm investigating approaches to solve this in a proper way without too much rework.

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
…ypes, r=jsha

rustdoc: render visibility on associated types

This should only affect inherent associated types (rust-lang#8995).
bors added a commit to rust-lang/rust-analyzer that referenced this issue Jan 3, 2024
feat: resolve inherent and implemented associated items in docs

This partially fixes #9694.

Supported:
- Trait methods and constants.
  * Due to resolution differences pointed out during the review of the PR, trait associated types are _not_ supported.
- Inherent methods, constants and associated types.
  * Inherent associated types are a [nightly feature](rust-lang/rust#8995), and are supported with no additional work in this PR.

Screenshot of VS Code running with the change:

<img width="513" alt="image" src="https://github.com/rust-lang/rust-analyzer/assets/7189784/c37ed8b7-b572-4684-8e81-2a817b0027c4">

You can see that the items are resolved (excl. trait associated types) since they are semantically highlighted in the doc comment.
@fmease fmease changed the title Tracking issue for inherent associated type. Tracking issue for inherent associated types Jan 5, 2024
@fmease fmease added S-tracking-impl-incomplete Status: The implementation is incomplete. and removed S-tracking-unimplemented Status: The feature has not been implemented. labels Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-inherent_associated_types `#![feature(inherent_associated_types)]` S-tracking-impl-incomplete Status: The implementation is incomplete. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests