Tracking Issue for "More Qualified Paths"

View all comments

This is a tracking issue for the "more qualified paths" feature. This feature originally grew out of a bug report #79658 where structs with qualified paths could not be constructed or used in patterns.

For instance:

fn main() {
    let <Foo as MyTrait>::Assoc { a } = <Foo as MyTrait>::Assoc { a: 2 };
    // The above would previously not parse.
    assert!(a == 2);
}

struct StructStruct {
    a: i8,
}

trait MyTrait {
    type Assoc;
}

struct Foo;

impl MyTrait for Foo {
    type Assoc = StructStruct;
}

See the implementation PR #80080 for more detailed discussion.

The feature gate for the issue is #![feature(more_qualified_paths)].

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 feature Allow qualified paths in struct construction (both expressions and patterns) #80080
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

#80080

Rollup merge of rust-lang#86937 - rylev:tracking-more-qualified-paths…

@petrochenkov

cc @petrochenkov: It looks like this might interact with my higher-ranked closure RFC: rust-lang/rfcs#3216 (comment)

Since only lifetimes can be specified within a for<> binder (which I doubt will ever change, since lifetimes are the only generic 'kind' that we can erase), I think we can still disambiguate between the two cases by checking for ' token immediately following the for < - a qualified path cannot start with a ', and a for<> binder can only start with a '.

Does that sound correct to you?

Since only lifetimes can be specified within a for<> binder (which I doubt will ever change, since lifetimes are the only generic 'kind' that we can erase)

Personally I'm really hoping to someday see closures with generic type parameters in Rust, similar to what exists in C++. There's no need to erase the type parameter; you "just" desugar to a generic Fn* impl, so, e.g.,

for<T> |x: T| { ... }

would be like

struct MyClosure;
impl<T> FnOnce<(T,)> for MyClosure {
    type Output = ();
    ...
}

Though, this is of limited use unless you also have higher-ranked trait bounds, like

fn takes_generic_closure<F>(f: F)
    where F: for<T> FnOnce(T)
{ ... }

But that too is something I would like to see someday.

@Aaron1011

@Aaron1011
This ambiguity already exists in the language in a few places, like impl <T> :: A {} and some others, and we have some disambiguation rules for this case.
I think we need to reuse the same rules for the for<...> closure case too, without introducing more special cases.

Lack of stable support for this can be worked around with a simple type alias
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=92460c3c1d0931dc9fac47d8e9877a51

use std::ops::Range;

type Type<T> = T;

fn main() {
    let Type::<<Vec<Range<u8>> as IntoIterator>::Item> {start, end} =
        Type::<<Vec<Range<u8>> as IntoIterator>::Item> {start: 3, end: 5};
    
    assert_eq!(start, 3);
    assert_eq!(end, 5);
}

Where is this actually wanted? It seems extremely convoluted. Surely if you know the names of the fields, you know the name of the type? I was amazed to see this is already possible via the trivial workaround, and think this should absolutely not be encouraged.

The main use-case would be macros (for example, if you want to assert a type built from a user-provided type). However, I don't know if there are currently any macros in the wild that would benefit from this.

The situation where we name a concrete type via an associative type is quite regular in macros, yes.

However, I don't know if there are currently any macros in the wild that would benefit from this.

At least, #[cucumber::when] does.

This seems like it may be ready to stabilize. Could we get a stabilization report and documentation PR?

The situation where we name a concrete type via an associative type is quite regular in macros, yes.

Why is the proc macro unable to know the name of the concrete type?

Implement client-side trait methods for action messages

Action message support (#417)

Are there any blockers? I'd be happy to put up a stabilization PR.

Implement client-side trait methods for action messages

Just FYI this feature was merged into r-a right now.

Navigation Menu

Repository navigation

Tracking Issue for "More Qualified Paths" #86935

About tracking issues

Steps

Unresolved Questions

Implementation history

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for "More Qualified Paths" #86935

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

Aaron1011 commented on Mar 6, 2022

comex commented on Mar 7, 2022

petrochenkov commented on Mar 7, 2022

rodrimati1992 commented on Jun 4, 2022

jhpratt commented on Jul 25, 2022

Aaron1011 commented on Jul 25, 2022

tyranron commented on Jul 25, 2022

joshtriplett commented on Jul 27, 2022

jhpratt commented on Jul 27, 2022

15 remaining items

joshlf commented on Apr 8, 2025

victorteokw commented on Jul 24, 2025

ChayimFriedman2 commented on Mar 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions