Compiler doesn't explain that unfulfilled lifetime requirement comes from object lifetime default

[DanielSWolf]

Given the following code (Playground link):

use std::fmt::Display;

fn foo<T: Display>(value: T) -> Box<dyn Display> {
    let result: Box<dyn Display> = Box::new(value);
    result
}

The current output is:

error[E0310]: the parameter type `T` may not live long enough
 --> src/lib.rs:4:36
  |
4 |     let result: Box<dyn Display> = Box::new(value);
  |                                    ^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds
  |
help: consider adding an explicit lifetime bound...
  |
3 | fn foo<T: Display + 'static>(value: T) -> Box<dyn Display> {
  |

Ideally the output should look like:

error[E0310]: if the parameter type `T` contains references, variables of this type may not live long enough
 --> src/lib.rs:4:36
  |
4 |     let result: Box<dyn Display> = Box::new(value);
  |                                    ^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds
  |
help: consider excluding types with non-static references by adding an explicit lifetime bound...
  |
3 | fn foo<T: Display + 'static>(value: T) -> Box<dyn Display> {
  |

Rationale for the change:

I'm fairly new to Rust. When I first encountered this errors, there were three things about this message I didn't understand:

Do types have a lifetime?

The error message states that "the parameter type T may not live long enough". In non-generic code, Rust's error messages talk about the lifetimes of concrete variables, not the lifetimes of types. My understanding is that there is that types themselves always exist and that there is no such thing as the lifetime of a type, only the lifetime of a variable of that type. So I guess "the parameter type T may not live long enough" is just shorthand for "variables of type T may not live long enough". The latter would have made the error message clearer to me.

How can value not live long enough?

The only variable of type T is value. This variable is passed by value, not by reference, and thus moved. I just couldn't think of a scenario where this variable might not live long enough.

The answer, as I now realize, is that T may be a struct containing references, which in turn may have a limited lifetime. Given that this is the only problematic case, it would have helped me if the error message had explicitly mentioned it.

Must I really limit my function to arguments with static lifetime?

The error message suggests adding the explicit lifetime bound 'static to T. When I first came across this message, I didn't realize that "static" as a trait bound has a different meaning to "static" as a reference lifetime. I assumed that adding the trait bound 'static to T would allow only arguments with a static lifetime to be passed, making the function useless. This is not the case. It would have helped me if the suggestion had mentioned this in some way.

[lukas-code]

We should probably also add a hint that dyn Trait in return position means dyn Trait + 'static.

Your function is currently equivalent to this:

use std::fmt::Display;

fn foo<'a, T: Display + 'a>(value: T) -> Box<dyn Display + 'static> {
    let result: Box<dyn Display + 'a> = Box::new(value);
    result
}

Another fix would be to change it to this:

use std::fmt::Display;

fn foo<'a, T: Display + 'a>(value: T) -> Box<dyn Display + 'a> {
    let result: Box<dyn Display + 'a> = Box::new(value);
    result
}

@rustbot label D-papercut D-newcomer-roadblock

[kpreid]

Another way the message here could be improved is if “so that the type T will meet its required lifetime bounds” explained where the bounds arose — pointing at the dyn Display and mentioning what its elided lifetime bound is.

[CAD97]

The words I'd personally lean towards trying to fit in is (in addition to clarifying where the 'static requirement comes from) mentioning more explicitly that T can capture lifetimes (making it non-'static).

Something along the lines of formatting this closer to a standard lifetime outlives requirement and "desugaring" the implicit dyn (+ 'static) and for<'0> T: '0 lifetimes in order to point to them.

I also agree that this error should suggest relaxing the 'static bound in addition to the current suggestion of restricting the T parameter.

[QuineDot]

I agree that the return type should be highlighted as the source of the requirement, with the Box<dyn Display + 'static> expanded, and an alternative suggestion of a non-'static version be added.

I would refer to "non-'static lifetime"s instead of references specifically, as not only references have lifetimes.

error[E0310]: type parameter `T` may include non-`'static` lifetimes, which will not live long enough
 --> src/lib.rs:4:36
  |
4 |     let result: Box<dyn Display> = Box::new(value);
  |                                    ^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds
  |
help: consider excluding types with non-`'static` lifetimes by adding an explicit lifetime bound...
  |
3 | fn foo<T: Display + 'static>(value: T) -> Box<dyn Display> {
  |

I think the longer E0310 page could also be improved:

• Type parameters in type definitions have lifetimes associated with them that represent how long the data stored within them is guaranteed to live

  I find this comes off weird since the lack of a lifetime being associated is the problem. I'm not sure it's worth it to go into "T must last for at least the function body, but perhaps no more", or if it just needs "may have lifetimes associated".

• Include something to correct common lifetime misconception #1: T only contains owned types

  • This could be a good place to use an example of T = &'short Whatever

[DanielSWolf]

I would refer to "non-'static lifetime"s instead of references specifically, as not only references have lifetimes.

I guess part of the problem is that the same message needs to make sense both to new and to seasoned Rust developers. As a Rust newbie, I like seeing the word "references" in there, because it illustrates the problem in terms I understand (thus answering my second question in the OP). As an experienced Rustacean, you (rightfully) expect a message that is technically correct.

Maybe the two can be combined by giving references as an example, like this?

 type parameter `T` may include non-`'static` lifetimes such as references, which will not live long enough

[estebank]

This is likely a duplicate of #41966. Keeping it open due to all the additional context.

[BPodszun]

As another new user to Rust I absolutely agree with the initial submission (and thank the person for properly explaining it). Note that this isn't just about the (implicit) return type of functions. I ran into this by tokio::spawn-ing a task and got the same error. My function has no return type.I agree that the wording "lifetime of a type parameter" is really confusing when you're new.

Unrelated, but I only learned that 'static doesn't just mean static but also "I promise I don't have any references" from this ticket, which probably caused the error message to be even more confusing.

Where I stumbled upon this: In a class that wraps an Arc<Mutex<HashMap>> with metadata/behavior I have a block that is impl<K, V> for MyThing<K, V> that looks like

fn spawn_a_task(&self, mut somesignal: mpsc::Receiver<K>) {
    tokio::spawn(async move {
        while let Some(foo) = &somesignal.recv().await { /* omitted */ }
    }
}

There's no return type in the signature although async complicates things and I get the error about K and V here just like in the original examples.

[jshaw-jump]

I ran into this error recently and the confusing bit for us was that the message doesn't indicate where the bound exists which made it difficult to track down the error.

struct Foo<T>(T);

impl<T: 'static> Foo<T> {
    fn fun(&self) {}
}

fn bar<T>(v: Foo<T>) {
    v.fun();
}

The above produces the following which does not reference the bound on impl Foo.

error[E0310]: the parameter type `T` may not live long enough
 --> src/lib.rs:8:5
  |
8 |     v.fun();
  |     ^^^^^^^
  |     |
  |     the parameter type `T` must be valid for the static lifetime...
  |     ...so that the type `T` will meet its required lifetime bounds
  |
help: consider adding an explicit lifetime bound
  |
7 | fn bar<T: 'static>(v: Foo<T>) {
  |         +++++++++

If you change 'static to Send, you get a much nicer error which clearly indicates the location of the bound which causes the violation.

error[E0599]: the method `fun` exists for struct `Foo<T>`, but its trait bounds were not satisfied
 --> src/lib.rs:8:7
  |
1 | struct Foo<T>(T);
  | ------------- method `fun` not found for this struct
...
8 |     v.fun();
  |       ^^^ method cannot be called on `Foo<T>` due to unsatisfied trait bounds
  |
note: trait bound `T: Send` was not satisfied
 --> src/lib.rs:3:9
  |
3 | impl<T: Send> Foo<T> {
  |         ^^^^  ------
  |         |
  |         unsatisfied trait bound introduced here
help: consider restricting the type parameter to satisfy the trait bound
  |
7 | fn bar<T>(v: Foo<T>) where T: Send {
  |                      +++++++++++++