Why this code having a warning(even hard error in future)

fn f<'k, 'b, T: 'b>(_: &'k mut &'b mut T) {}

pub fn fx<'a: 'c, 'c, T: 'a, U>(_: &'c mut &'a mut T) -> fn(&mut &'a mut U) {
    f::<'a, U>


   Compiling playground v0.0.1 (/playground)
warning: cannot specify lifetime arguments explicitly if late bound lifetime parameters are present
 --> src/main.rs:5:9
2 | fn f<'k, 'b, T: 'b>(_: &'k mut &'b mut T) {}
  |      -- the late bound lifetime parameter is introduced here
5 |     f::<'a, U>
  |         ^^
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #42868 <https://github.com/rust-lang/rust/issues/42868>
  = note: `#[warn(late_bound_lifetime_arguments)]` on by default

I have read issue #42868, made no sense.
It says:

It's not clear how to provide arguments for early-bound lifetime parameters if they are intermixed with late-bound parameters in the same list.


Just removing the lifetime arguments pointed to by the lint should be enough in most cases.

I don't understand, in my case, because it hard to figure out which one of 'k' or 'b corresponds 'a in f::<'a, U>, (and it can be figured out, specifying a late-bound life time is an error, so the compiler choose 'a ===> 'b in this case) then 'a has to be removed?

Well, 'b in fn f<'k, 'b, T: 'b>(_: &'k mut &'b mut T) is early bound, f::<'a, U> and f::<'c, U> are different
If I remove the life time, e.g. f::<U>,how can I express the diffidence?

No. It's not different. Rust will not have different codegen on lifetime parameter alone. 'k will just be a inferred lifetime that satisfies all the bounds.

They are different, not because of difference between 'k and 'b.

'a is different with 'c because they both direct to 'b, which in turn corresponds to 'a in in _: &'c mut &'a mut T.

in 'a case, it is _: &'c mut &'a mut T, only 'a: 'c is needed.
in ’c case, it is _: &'c mut &'c mut T, which requires both 'a: 'c and 'c: 'a as a result.

I can't tell what you do or don't understand. The potential ambiguity between the lifetimes ("hard to figure out which one") is what the first quote is talking about. Probably also the warning exists due to an aspiration to remove or weaken the early/late bound distinction (though I can't say how feasible, disruptive, or sound this may be).

f::<U> works for your example and only has one possible interpretation (due to the return type).

Ascription in a variable binding would also work.

It's possible there are scenarios where inference fails (wouldn't be a first for Rust). Feel free to post one if you know of one.

Reminder that the borrow checker checks for "I know a solution exists", and doesn't assert "the lifetimes are exactly this".

I don't understand why this lint exists, and even be a hard error in future.

  1. If you don't understand early/late (why would the typical programmer, it's in no official documentation and only relevant in niche situations with confusing errors), it's unclear why some lifetimes can be omitted or which ones the explicit ones correspond to

  2. There's aspiration to weaken or remove the late/early distinction (speculation on my part; reskimming the issue, those aspirations might be newer than the lint)

1 Like

Oh and the future compatibility line implication that this will definitely be an error in the future is a lie in at least some cases (both past lints now allowed, and current lints planned to be allowed).

How likely or not it is in this particular case, I have no idea.

(@ekuber - sorry to ping, but could the wording be adjusted? The non-truthfulness is often annoying and sometimes dangerous.)

Seems the lint is correct.

I can't find a case in which early bound lifetime should be explicitly specified --- NOT only early-bound lifetimes which intermixed with later-bound lifetimes, seems all early-bound lifetimes can be inferred properly without explicitly specified any of them.

Maybe there are such cases, I can't to find one by myself.

Yes, tweaking the wording to make it more accurate is possible. Let's file a ticket so we don't forget to do it.

1 Like


This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.