About #10:
> because to unify them at this point would be a breaking change
Couldn't they change this in a future edition without breaking older editions?
> because to unify them at this point would be a breaking change
Couldn't they change this in a future edition without breaking older editions?
In short, yes, but be very wary.
Because you can pass closures into functions across crate boundaries, which requires consistent lifetime semantics, I find it unlikely that this will be implemented.
A more problematic thing is that `cargo fix --edition` should be able to transform existing code to the same meaning in a new edition, so there should be a way to opt-in for the old behavior.
However, if you don't specify the argument type, it compiles fine. It's rare that you need to specify argument or return types on a closure, so it's not actually a large issue.
fn requires_static(_: &'static str) {}
let long_lifetime: &'static str = "";
let closure = |_input: &str| -> &str { long_lifetime };
let short_lifetime = &String::new();
requires_static(closure(short_lifetime));