lifetime elision for return type can refer to an explicitly named region

[lcnr]

Originally posted by @danielhenrymantilla in #117967 (comment)

I would nonetheless like to take this opportunity to talk a bit about:

Aside: edge cases of lifetime elision rules which are confusing

There are two slightly related aspects which can make lifetime elision rules (w.r.t. the output elided lifetime) be rather confusing, or poorly readable.

1. The gist of it is that output '_ can "connect"/match an input explicitly named lifetime "parameter".
2. Worse, in certain cases this named lifetime "parameter" may not be generic at this layer (outer generic parameter), or may not be generic at all ('static hard-coded / fixed value)!

To illustrate, consider:

type Metadata = &'static str;

struct Foo<'lt>(&'lt str);

impl<'lt> Foo<'lt> {
    fn a(this: Self, metadata: &'static str) -> &str;
    fn b(this: Foo<'lt>, metadata: Metadata) -> &str;
}

• Demo

I personally find the capability of type aliases or Self aliases to affect semantics (here, those of lifetime elision rules) to be appaling.

It would thus be nice if certain efforts were made to try and go in the other directions, e.g., by linting whenever an output-elided lifetime ('_-explicitly, or implicitly) happens to match an explicitly named input lifetime param, and even more so when this input lifetime "param" is 'static or stems from an outer scope.

[traviscross]

CC:

• Split elided_lifetime_in_paths into tied and untied #120808
• Add a new mismatched-lifetime-syntaxes lint #138677

[traviscross]

See also:

• Oddity with lifetime elision and type aliases #140611