Tracking Issue for "More Qualified Paths"

[rylev]

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

[Aaron1011]

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?

[comex]

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.

[petrochenkov]

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

[rodrimati1992]

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

[jhpratt]

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.

[Aaron1011]

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.

[tyranron]

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.