Tracking Issue for enabling `elided_lifetimes_in_paths` lints

[scottmcm]

This issue tracks getting the currently-allow-by-default elided_lifetimes_in_paths lint https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#elided-lifetimes-in-paths into a place where it can be enabled by default.

Context

(This was formerly in the in-band lifetimes tracking issue, #44524, but is being split out because it doesn't actually depend on in-band specifically now that '_ is stable.)

There seems to be general agreement amongst lang that lifetimes that participate in elision should be visible. That means things like

-fn foo<T>(x: &T) -> Foo<T>
+fn foo<T>(x: &T) -> Foo<'_, T>

and

-fn foo<T>(x: Foo<T>, y: Bar<T>) -> &T
+fn foo<T>(x: Foo<'_, T>, y: Bar<T>) -> &T

However, there's less agreement whether they're needed in other places. For example, whether it's valuable to require showing the lifetime in

 impl fmt::Debug for StrWrap {
-    fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
+    fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
         fmt.write_str(self.0)
     }
 }

A comment against needing that kind of '_: #44524 (comment)
And one saying it's helpful to show it: #44524 (comment)

(If anyone remembers where lang discussed this and has notes about it, please post or edit this comment!)

Perhaps one way to make progress is to start splitting up the lint to isolate the different cases?

Related discussions

• Elided lifetime changes in rust_2018_idioms lint is very noisy and results in dramatically degraded APIs for Bevy #131725

Current status

• PR to split up elided_lifetimes_in_paths into two separate lints under the same lint group: Split elided_lifetime_in_paths into finer-grained lints #120808

Unresolved questions

• For Split elided_lifetime_in_paths into finer-grained lints #120808, what should the split-up lints be called, i.e. are "tied" vs "untied" terminology sufficiently clear?

[cjgillot]

I agree it's high time we turned this lint by default. I'd even go as far as making it a future-compatibility lint and make it a hard error in a few releases.
However, splitting the different cases might not help much. The current lint is about elided lifetimes in types, which is purely syntactic. Changing the lint depending on lifetime resolution will probably make it very confusing. (Besides, I'm not even sure most users know elided lifetime resolution rules.)

[scottmcm]

Yeah, I don't think we ever came to a confident opinion of where the right balance is.

Spitballing: one simple syntactic rule that's (hopefully) uncontroversial would be "all lifetimes in return types must be visible". So it's always -> Ref<'_, T> or -> Ref<'blah, T>.

I don't think just that much is sufficient, but it could be a good starting point.

[petrochenkov]

One example where this makes life harder.

Yesterday I wanted to add one more lifetime parameter to struct ExtCtxt<'_> { ... } in the compiler (to avoid passing things by value to extern_mod_loaded callback).

That would require changing about 170 uses of ExtCtxt<'_> across the compiler to ExtCtxt<'_, '_>, mostly in function parameters.
As a result I avoided making an otherwise reasonable change in favor of keeping the existing hack with consuming and returning Vec<Attribute> and Vec<P<Item>>, which may be not pretty, but at least it's local and doesn't have an effect on the rest of the codebase.

If elided lifetimes in paths are kept explicit, then I guess we need something like '.. to make changes like this have a better cost-benefit ratio.
'.. means "as many '_s as necessary", similarly to the ".." -> "_, _, _" transformation in patterns.

[scottmcm]

I think that would be useful in impl headers too. I just noticed this one:

-impl<'a, 'b, 'tcx> fmt::Debug for Elaborator<'a, 'b, 'tcx> {
+impl fmt::Debug for Elaborator<'_, '_, '_> {

Where being able to say for Elaborator<'..> seems very reasonable to me.

EDIT: Oh, hey, I found a Sept 2018 post where I brought up '.. 🙃 #44524 (comment)

[Aaron1011]

Here's a case where it would be useful to have an explicit '_ in an argument:

In #91831 (comment), the following code:

struct Foo<'a>(&'a i32);

impl<'a> Foo<'a> {
    fn modify(&'a mut self) {}
}

fn bar(foo: &mut Foo) {
    foo.modify();
}

produces the following error:

error[E0623]: lifetime mismatch
 --> src/lib.rs:8:9
  |
7 | fn bar(foo: &mut Foo) {
  |             --------
  |             |
  |             these two types are declared with different lifetimes...
8 |     foo.modify();
  |         ^^^^^^ ...but data from `foo` flows into `foo` here

The error message itself is not great ("these two types" doesn't make much sense), but it's made even worse by the fact that &mut Foo is hiding a lifetime (it's really &mut Foo<'_>). When reading over the error, it took me a minute to realize that there were actually two distinct lifetimes in the signature of bar, not just one.

As mentioned earlier, having &mut Foo<'_> also gives an error message a nicer place to point at. For example, we get this under -Z borrowck=mir:

error: lifetime may not live long enough
 --> foo.rs:8:5
  |
7 | fn bar(foo: &mut Foo<'_>) {
  |             -        -- let's call this `'2`
  |             |
  |             let's call the lifetime of this reference `'1`
8 |     foo.modify();
  |     ^^^^^^^^^^^^ argument requires that `'1` must outlive `'2`

error: aborting due to previous error

[koute]

I'd even go as far as making it a future-compatibility lint and make it a hard error in a few releases.

I sincerely hope that this isn't made into a hard error, because as soon as this lint is turned on by default I'll be permanently disabling it for all of my projects.

As @petrochenkov said this just makes it painful to refactor code in certain cases (no, I don't want to add a '_ a thousand times across my whole codebase every time I fiddle with the lifetimes on my types), makes things less ergonomic and just introduces extra visual noise. All that for not that much gain in my opinion.

Working with Rust every day the number of times I've hit an issue with which this would help is maybe once or twice a year. I don't know, maybe I'm just good with lifetimes, so I'm not going to say whether it should be the default or not, but I personally very strongly do not want this lint, as to me it essentially brings no value and is just a lint in search of a problem. If the issue here is confusing error messages we could just simply improve them so that they show the elided lifetimes.

[Globidev]

In contrast to:

Working with Rust every day the number of times I've hit an issue with which this would help is maybe once or twice a year

Helping beginners in Rust every day, I can't even count the number of times where someone has been asking for help by posting a snippet of code that had elided lifetimes in some paths which made it obscure for others to understand the lifetime issue that was involved.
For some of the beginners in question, it made them think that lifetimes were not actually involved since they could elide them, which led to more confusion.
More generally, not specifying that tiny extra '_ makes it hard to reason locally about an issue when you're not the author of the code (and probably even when you become your future self).

[koute]

In contrast to:

Working with Rust every day the number of times I've hit an issue with which this would help is maybe once or twice a year

Helping beginners in Rust every day, I can't even count the number of times where someone has been asking for help by posting a snippet of code that had elided lifetimes in some paths which made it obscure for others to understand the lifetime issue that was involved. For some of the beginners in question, it made them think that lifetimes were not actually involved since they could elide them, which led to more confusion. More generally, not specifying that tiny extra '_ makes it hard to reason locally about an issue when you're not the author of the code (and probably even when you become your future self).

This sounds like perhaps the error messages could be improved to make it less confusing for the beginners? Or perhaps improve the IDE experience so that the IDE automatically shows you those '_ without you having to write them out by yourself (if it doesn't already; I don't use this feature so I don't know), just like it can currently show you the elided types as seen here:

Type elision can also be confusing for beginners, and yet we aren't advocating for people to always explicitly type them out and we're happy with an IDE-based solution; can't we just do the same for elided lifetimes?

[Globidev]

Type elision can also be confusing for beginners, and yet we aren't advocating for people to always explicitly type them out and we're happy with an IDE-based solution; can't we just do the same for elided lifetimes?

Rust currently does not allow any kind of type elision in paths though, which is the only scope affected by this lint. You always have to explicit the types in your function's signature and we don't allow eliding any kind of type or const generic parameters either.

fn foo(x: Vec) { … }

is not valid and probably for a good reason: it would be hard to see at a glance that foo is actually generic
We can probably apply a similar reasoning to lifetime generics: for types other than plain references, it's not obvious that lifetimes would be involved

[kpreid]

What about just enabling warn(elided_lifetimes_in_paths), with no specific plan to then make it an error? Then beginners get the help (at least, those who read warnings when they also have errors), and those who find the elided syntax useful can turn the lint off. That seems to me to be a substantial net improvement on the status quo.