Disallow type/lifetime parameter shadowing.

[nikomatsakis]

Just what it says in the subject.

Rendered view.

[nikomatsakis]

Note: there was some (universally positive) discussion in a discuss thread already: http://discuss.rust-lang.org/t/preventing-lifetime-shadowing/784

[Manishearth]

Agree with this.

[Valloric]

👍 I've been bitten by this several times.

[TyOverby]

This was my number 1 pain point when learning about lifetimes.

[huonw]

I would be interested to see a mention of hygiene/macro-generated type/lifetime parameters, e.g. the following would preferably be valid:

macro_rules! method {
    () => {
        fn foo<'a>(&'a self) -> &'a int { unimplemented!() }
    }
}

struct Foo<'a> { x: &'a int }
impl<'a> Foo<'a> {
    method!()
}

[Manishearth]

@huonw In general macros allow a kind of "shadowing" which isn't really shadowing, where internally the hygiene keeps the identifiers separate, but when something errors it is possible to get similar tautological errors ("expected 'a but found 'a", etc).

Perhaps identifiers from macros should be visibly mangled in errors where this happens, or something? ('a#1, 'a#2, etc)

[huonw]

In general macros allow a kind of "shadowing" which isn't really shadowing, where internally the hygiene keeps the identifiers separate

@Manishearth yes, I agree, I would just like this to be explicit in the RFC to ensure there's no ambiguity in the implementation. Disallowing shadowing could be interpreted as disallowing textual names that are the same (rather than the whole identifiers: name and hygiene), and, macros do not allow for completely arbitrary shadowing, e.g. writing fn foo() {} macro_that_expands_to_another_fn_foo!() is not legal.

[Manishearth]

Agreed; the RfC should explicitly mention that it's not going to change the pseudoshadowing that macros allow.

[blaenk]

This is a great idea.

[bstrie]

We had someone hit this just today in IRC. They had fn foo<T> defined inside of impl<T>, which yielded an unhelpful and understandably cryptic expected core::option::Option<&T>, found core::option::Option<&T> (expected type parameter, found a different type parameter).

I already voiced my support in Discuss, but let me emphasize again that this would be a good change.

[nrc]

We discussed this in (this week's meeting)[] and decided to accept. FTR, there was some debate about whether this should be a lint or a hard error (I personally pushed for a lint). We decided on a hard error because it is easier to implement and more conservative. We may (should) revisit this decision post-1.0.

Tracking issue