Skip to content

Fix rule ordering of trait object lifetime elision #2281

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.

Sign up for GitHub

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

Open
fmease wants to merge 1 commit into
base: master
Choose a base branch
from
+11 −11
Open

Fix rule ordering of trait object lifetime elision #2281

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions src/lifetime-elision.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,26 +94,26 @@ These default object lifetime bounds are used instead of the lifetime parameter
r[lifetime-elision.trait-object.explicit-placeholder]
If `'_` is used as the lifetime bound then the bound follows the usual elision rules.

r[lifetime-elision.trait-object.containing-type]
If the trait object is used as a type argument of a generic type then the containing type is first used to try to infer a bound.

r[lifetime-elision.trait-object.containing-type-unique]
* If there is a unique bound from the containing type then that is the default.

r[lifetime-elision.trait-object.containing-type-explicit]
* If there is more than one bound from the containing type then an explicit bound must be specified.

r[lifetime-elision.trait-object.trait-bounds]
If neither of those rules apply, then the bounds on the trait are used:
The bounds on the trait are used:

@fmease fmease Jun 8, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the phrasing of this rule and its "lack of informative value". It's a consequence of me having almost mechanically swapped these two "groups" of rules...

View changes since the review


r[lifetime-elision.trait-object.trait-unique]
* If the trait is defined with a single lifetime _bound_ then that bound is used.

@fmease fmease Jun 8, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that we look at the outlives-bounds of the trait and any of its supertraits. I was wondering whether you consider this obvious / implied from the current wording or if it's actually unclear.

Personally I'm slightly leaning toward the latter, in my eyes it could be misinterpreted to mean just the "syntactic" bounds on the traits...

View changes since the review


r[lifetime-elision.trait-object.static-lifetime]
* If `'static` is used for any lifetime bound then `'static` is used.

r[lifetime-elision.trait-object.containing-type]
If neither of those rules apply and the trait object is used as a type argument of a generic type then the containing type is first used to try to infer a bound.

r[lifetime-elision.trait-object.containing-type-unique]
* If there is a unique bound from the containing type then that is the default.

r[lifetime-elision.trait-object.containing-type-explicit]
* If there is more than one bound from the containing type then an explicit bound must be specified.

r[lifetime-elision.trait-object.default]
* If the trait has no lifetime bounds, then the lifetime is inferred in expressions and is `'static` outside of expressions.
* If there is no such container, then the lifetime is inferred in expressions and is `'static` outside of expressions.

```rust
// For the following trait...

@fmease fmease Jun 8, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Add examples that demonstrate this ordering. None of the current examples exercise it FYI.

View changes since the review

Expand Down
Loading