Tracking issue for lifetime elision for impl headers (feature impl_header_lifetime_elision)

[aturon]

The lifetime elision RFC included rules for eliding lifetimes in impl headers, but these rules were not included in the implementation.

Mentoring instructions can be found here.

[pnkfelix]

triage: P-low

[nikomatsakis]

See here for a summary of the current status.

[sophiajt]

Should this be P-low since @brson notes it as a critical part of the implementation?

[aturon]

@jonathandturner I think there's some confusion -- @brson was referring to error messages, which I believe at this point are largely as specified (but would be worth checking). This issue, OTOH, is about adding an additional point of elision.

I'm nominating this for lang team discussion -- the RFC for this feature is quite old, and at this point I think we should revisit whether we even want to do it.

[nikomatsakis]

We discussed in the @rust-lang/lang meeting today and decided that there is no reason to expire an RFC just because it's been a while. Basically, the motivation of the RFC still seems fairly relevant. That said, we would expect that if these changes were implemented, they would go through a stabilization period, and so if people felt like they were now bad, we could address that then.

It's worth noting here for the record a few random thoughts of my own. First, I feel like elision has been wonderful except for one case: fn foo(&self) -> Bar where Bar has lifetime parameters (struct Bar<'x>). In this case, I feel like the fact that Bar "extends" the borrow of self is subtle. This becomes worse when there are other named lifetime parameters that appear in the return type, for example fn foo(&self) -> &'a Bar, which would expand to fn foo<'b>(&'b self) -> &'a Foo<'b>. I'd love if we could find some way to lint against harmful patterns and provide a lightweight way to indicate that there are lifetimes in Bar without having to name them.

[djc]

I might be interested in working on this. Can someone outline some steps to get going? What's the perceived complexity factor here? (I have contributed small things before, but no actual compiler work.)

[eddyb]

@djc You might want to start by taking a look at #39265, which stabilized 'static elision in const & static (by removing the special casing it needed for feature-gating), and which touched the new version of the elision system in resolve_lifetime, hopefully the site of most of your changes.

I worry that impl headers would want early-bound lifetime parameters so you'd need to synthetize those in a way that librustc_typeck/collect.rs understands and keeps track of in the impl's ty::Generics.

It still wouldn't be that hard, as impl lifetime/type parameters are never exposed to the user (instead, they're inferred from Self and trait parameters, where applicable), but it's unlike other forms of elision.

[nikomatsakis]

I'm definitely keen on seeing this done. @djc if you want I can try to draw up somewhat more detailed instructions that what @eddyb provided, but let me know.