Are those Reference parts completely wrong/outdated?

Path patterns (src):

Qualified path patterns can only refer to associated constants

How about this? -> <Enum>::A
Couldn't this be used as a qualified path pattern, for example in match arms?

Trait bounds (src):

Bounds that don't use the item's parameters or higher-ranked lifetimes are checked when the item is defined. It is an error for such a bound to be false

This below is not checked on definition:

// Compiles on its own
//             vvvvvvv higher-ranked trait bound (HRTB)
fn foo() where for<'a> String: Copy {}

fn main() {
    // error to call it (this is where the HRTB is checked)
    foo();
}

And this is checked on definition:

struct A<'a, T>
where
    i32: Iterator,          // Error: `i32` is not an iterator
{
    f: &'a T,
}

fn main() {
}

So it looks like bounds that don't use the item's parameters are checked on definition, but higher-ranked lifetimes are not.

Temporary scopes (src):

Apart from lifetime extension, the temporary scope of an expression is the smallest scope that contains the expression and is one of the following:
(...)

The second operand of a lazy boolean expression.

It looks like LHS is a temporary scope, too.
Playground example provided by @CAD97 from rust.internals

(forum discussion)

For the qualified path patterns, that is indeed not updated, and is tracked in #631.

For the HRTB validation, that looks like a bug in rustc to me. It looks like it changed in rust-lang/rust#84682. I can't offhand think of a HRTB that would inherently be false, so I'm not sure what the original text was referring to.

For the lazy boolean drop scope, it looks like that changed in rust-lang/rust#103293 but the reference was never updated.

Can the reference part of qualified path patterns be quickfixed or rather it should be done as a part of whole "type_alias_enum_variants documentation" (as stated in #631)? I'm asking because I'm planning to propose some reference fixes and improvements in near future and I may include it.

It's fine to make incremental progress. Just keep in mind that it is very helpful to point to the reasoning why something changed (like an RFC, stabilization report, or a PR description), and bonus points if you can point to the compiler tests that exhibit the change and the location in the compiler where the relevant behavior is implemented.

I'm going to close as I believe the questions here have been answered, and the first item is a duplicate of #631, and the drop scope has been fixed in #1681. Thanks for bring it up!

Navigation Menu

Repository navigation

Are those Reference parts completely wrong/outdated? #1587

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Are those Reference parts completely wrong/outdated? #1587

Description

Activity

ehuss commented on Aug 24, 2024

WiktorPrzetacznik commented on Aug 24, 2024

ehuss commented on Aug 26, 2024

ehuss commented on Mar 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions