Tracking issue for RFC 2115: In-band lifetime bindings

[aturon]

Update for 2022: With the FCP close finished, this is no longer on a stabilization path, and will likely be removed from nightly. The issue will remain open so long as it's referenced by an implemented feature in the compiler, however.

---

This is a tracking issue for the RFC "In-band lifetime bindings" (rust-lang/rfcs#2115).

Steps:

• Stabilize '_ (this has its own tracking issue, Tracking issue for '_ #48469)
• Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872: Enable elision in impl headers (mentoring instructions here)
  • Now tracked by impl_header_lifetime_elision in Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872
• enable elision in where-clauses on functions #45667: Support '_ in where-clauses on functions. -- blocked on Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision) #15872
• in-band lifetimes: enable implicit binders #46042: Enable implicit binders.
• Lint against single-letter lifetimes not confined to functions (?)
• Lint against single-use lifetimes: In-band lifetimes: Lint against single-use lifetime names #44752
  • note: @pnkfelix added this as a "prereq", but its possible we do not have consensus that it is required (though @pnkfelix believes it was part of the RFC...)
• Apply to rustc, experimenting with naming conventions (e.g., working through the affect on rustc).
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• What conventions should we use for lifetime names, and should they be enforced via lint?
  • Considerations:
    • To help avoiding accidental shadowing, make it easy to know where a lifetime name is bound (and in particular if it is bound in some enclosing, possibly out-of-sight, scope).
    • Permitting "well-known" names like 'tcx and 'gcx to be used consistently
  • Some prior proposals:
    • Names bound in impls are upper-case (but: fails to permit well-known names)
    • Single-letter names cannot be bound across scopes (but: can't easily tell if longer names are bound across scopes or not)
• Can we find an unequivocally-better syntax than '_ for elided lifetimes?
  • These are now stable, so we didn't

Known bugs (possibly incomplete list):

• In-band lifetimes stop working when in a nested function #52532

[glaebhoerl]

@aturon Could we word the unresolved question as something like "what is the appropriate convention, if any" rather than "is this particular convention worthwhile"? Thanks!

[vitiral]

also, that wasn't the only suggested alternative. There is also completely explicit lifetimes using 'self::lifetime_name

[durka]

$ rg -F "impl<'a>" /rust/src | wc -l
     730

This supposedly ergonomic change is going to require updating a lot of code, including all of our docs and examples. I guess you could just do s/'a/'aa but that seems to miss the point. Could we make some kind of interactive rustfix tool to let you choose new lifetime names and have them automatically updated?

[aturon]

@glaebhoerl Done, thanks!

[nikomatsakis]

I expanded the unresolved question a bit.

[nikomatsakis]

Mentoring instructions

I'm not sure 100% the best way to implement this yet, but let me start by giving some pointers. Perhaps @eddyb can elaborate, as he is the last one to touch the relevant code in a serious way, as far as I know.

First thing is a kind of list of what the tasks are in the RFC. This is roughly the order in which I think we should approach them. It may even be worth breaking this out into separate issues.

XXX task list moved into main header

I don't have time for detailed mentoring notes, but here are a few things to start reading into. At present, region resolution etc kind of works like this:

• During HIR lowering, we insert placeholders for elided lifetimes.
• After HIR lowering, we run the code in resolve_lifetime.rs.
• This creates the NamedRegionMap that, for each hir::Lifetime, contains a Region struct indicating what region is being named.
  • This struct is a bit complicated. =)

[eddyb]

To support '_ we have to do very little:

• treat it like the existing placeholder lifetimes in hir::Lifetime::is_elided
• remove the error for literally using '_ as a lifetime

[SimonSapin]

Lint against single-letter lifetimes not confined to functions

Sorry that I come “after the battle” (this RFC was accepted during the pre-impl-period rush), but as @durka pointed out applying this lint to existing code bases will likely generate a lot of busy work for questionable benefits. I looked for the rationale for this lint but couldn’t find it. https://rust-lang.github.io/rfcs/2115-argument-lifetimes.html#lifetimes-in-impl-headers mentions a “convention”, but doesn’t say why enforcing it is important enough to warn by default. We don’t have such a lint for local variable names or field names, for example.

I assume that proposed lints are intended to warn by default. If they’re silent by default I have no concern.

[rpjohnst]

The idea is that there will no longer be <'a> sections in functions, so it will be harder to tell apart lifetime names from impl scope and those from function scope. This makes it tricky to know whether a name used in a function is intended to refer to an impl-scope lifetime, or to define a new one (and should thus be renamed).

[SimonSapin]

@rpjohnst Sorry, I have a hard time figuring out if your comment is arguing for or against something, and whether that thing is the lint I mentioned or some other change proposed by this tracking issue.

[rpjohnst]

@SimonSapin It's just trying to describe the reasoning behind the lint's existence, not necessarily argue for or against it.

[nikomatsakis]

@rfcbot fcp reviewed

I agree with what @scottmcm wrote. I am definitely still interested in us spending time to address some of the ergonomic pain around using lifetimes, but I'd want to step back and do an initiative, and in particular to spend some time identifying precisely which problems are most pressing now.

[scottmcm]

@davidtwco @estebank @nagisa Friendly one-week ping for the FCP close here. It only needs one more ✅!

[davidtwco]

@davidtwco @estebank @nagisa Friendly one-week ping for the FCP close here. It only needs one more ✅!

✅

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[matklad]

One no-brainer thing we can do to help here is to add an in-editor fix to create a declaration for “in-band” lifetimes

rust-lang/rust-analyzer#11039

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

[scottmcm]

With the FCP completed here, this is currently open because the feature still exists in the compiler, with the tracking issue number referencing this item:

rust/compiler/rustc_feature/src/active.rs

Line 401 in 9747ee4

(active, in_band_lifetimes, "1.23.0", Some(44524), None),

We're unsure how difficult it will be to remove the code about this from the compiler, but if anyone is interesting in picking up something, grepping for the feature should give a bunch of places to start:

https://github.com/rust-lang/rust/search?q=in_band_lifetimes+path%3Acompiler