NLL error on closure, but not on equivalent function

[Avi-D-coder]

With the 2018 edition on nightly or #![feature(nll)]:

fn main() {
    let _v_lambda = |v: &Vec<String>| v.iter().chain(v.iter()).collect::<Vec<&String>>();
}

fn _v_fn(v: &Vec<String>) -> Vec<&String> {
    v.iter().chain(v.iter()).collect::<Vec<&String>>()
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
warning: unsatisfied lifetime constraints
 --> src/main.rs:2:39
  |
2 |     let _v_lambda = |v: &Vec<String>| v.iter().chain(v.iter()).collect::<Vec<&String>>();
  |                         -           - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'1` must outlive `'2`
  |                         |           |
  |                         |           return type of closure is std::vec::Vec<&'2 std::string::String>
  |                         let's call the lifetime of this reference `'1`
  |
  = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
          It represents potential unsoundness in your code.
          This warning will become a hard error in the future.

    Finished dev [unoptimized + debuginfo] target(s) in 0.55s
     Running `target/debug/playground`

[memoryruins]

Using the above playground:

• Stable / Nightly 2015
  • Builds without warning / error
• Nightly 2015 #![feature(nll)]
  • error: unsatisfied lifetime constraints
• Nightly 2018
  • warning: unsatisfied lifetime constraints
  • (downgraded due to migrate mode)

Attempting to then use _v_lambda on stable 2015 or nightly 2018 on a &Vec<String> creates the following error on both with or without NLL

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter in function call due to conflicting requirements

_v_fn builds and runs on both.

[pnkfelix]

I am curious whether the lifetime elision rules are part of the reason we see the discrepancy here.

[pnkfelix]

(though my personal suspicion is that NLL is buggy and ignoring the constraint that the the input and the output types on the closure are supposed to use the same lifetime.)

[pnkfelix]

e..g this does compile under NLL:

fn _v_closure<'a: 'b, 'b>(_: &'b (), _: &'a ()) {
    let _v_lambda = |v: &'a Vec<String>| -> Vec<&'b String> {
        v.iter().chain(v.iter()).collect::<Vec<&String>>()
    };
}

[pnkfelix]

and, just in case someone wants a potentially more useful workaround, this also compiles today under NLL:

fn _v_closure<'a, 'b>(_: &'b (), _: &'a ())
                     -> impl Fn(&'a Vec<String>) -> Vec<&'b String>
    where 'a: 'b
{
    |v| { v.iter().chain(v.iter()).collect::<Vec<&String>>() }
}

[pnkfelix]

triage: P-high (because this looks annoying and perhaps very misleading/frustrating to end users), but not Release milestone.

I'm opting to not put it on the Release milestone because I do not think we would need to back port a hypothetical fix for this to the beta channel; this is an instance where the NLL migration mode saves us from that pain.

[pnkfelix]

triage: assigning to self to look at either Friday or Monday.