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. =)