Skip to main content

## MISMATCHED_LIFETIME_SYNTAXES

# Static MISMATCHED_LIFETIME_SYNTAXES

Source

    pub static MISMATCHED_LIFETIME_SYNTAXES: &Lint

Expand description

The `mismatched_lifetime_syntaxes` lint detects when the same lifetime is referred to by different syntaxes between function arguments and return values.

The three kinds of syntaxes are:

1. Named lifetimes. These are references (`&'a str`) or paths (`Person<'a>`) that use a lifetime with a name, such as `'static` or `'a`.

2. Elided lifetimes. These are references with no explicit lifetime (`&str`), references using the anonymous lifetime (`&'_ str`), and paths using the anonymous lifetime (`Person<'_>`).

3. Hidden lifetimes. These are paths that do not contain any visual indication that it contains a lifetime (`Person`).

#### §Example

ⓘ

    #![deny(mismatched_lifetime_syntaxes)]

    pub fn mixing_named_with_elided(v: &'static u8) -> &u8 {
        v
    }

    struct Person<'a> {
        name: &'a str,
    }

    pub fn mixing_hidden_with_elided(v: Person) -> Person<'_> {
        v
    }

    struct Foo;

    impl Foo {
        // Lifetime elision results in the output lifetime becoming
        // `'static`, which is not what was intended.
        pub fn get_mut(&'static self, x: &mut u8) -> &mut u8 {
            unsafe { &mut *(x as *mut _) }
        }
    }

{{produces}}

#### §Explanation

Lifetime elision is useful because it frees you from having to give each lifetime its own name and show the relation of input and output lifetimes for common cases. However, a lifetime that uses inconsistent syntax between related arguments and return values is more confusing.

In certain `unsafe` code, lifetime elision combined with inconsistent lifetime syntax may result in unsound code.