In-band lifetimes stop working when in a nested function

[Mark-Simulacrum]

#![feature(rust_2018_preview)]

fn main() {}

struct Bar<'a>(&'a u32);

impl Bar<'a> {
    fn foo() {
        fn foo(_: &'a u32) { } // error: use of undeclared lifetime name `'a`
    }
}

https://play.rust-lang.org/?gist=d2b32bc0947a05fa0830a0d244dcb4fa&version=nightly&mode=debug&edition=2015

[petrochenkov]

The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner 'a is an illegal use of the outer 'a rather than an implicitly defined fresh lifetime.

[Mark-Simulacrum]

Hm, I don't think that's quite what I'd expect: previously using <'a> in that context would be fine because there is no shadowing so to speak, that is, this compiles:

fn main() {}

struct Bar<'a>(&'a u32);

impl<'a> Bar<'a> {
    fn foo() {
        fn foo<'a>(_: &'a u32) { }
    }
}

[petrochenkov]

From https://github.com/aturon/rfcs/blob/93259c2fb9a66d805d9f5c9c049df82aad2b5553/text/2115-argument-lifetimes.md#lifetimes-in-fn-signatures

Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case.

(In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)

[Mark-Simulacrum]

I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.

[durka]

IMO it should be an error, with a helpful note like the one you get when writing fn foo<T>() { fn foo(_: T) {} }. Let's not make in-band lifetimes any more confusing than they already are.

[Mark-Simulacrum]

The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.

[durka]

The problem is if it's allowed, then

impl Foo<'a> { fn foo(_: &'a u32) }

has a different meaning than

fn foo(_: &'a u32) { fn foo(_: &'a u32) {} }

This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between 'a and 'a won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.

[Mark-Simulacrum]

Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (Self, lifetimes, generics).