Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow type/lifetime parameter shadowing. #459

Merged
merged 1 commit into from Nov 29, 2014

Conversation

Projects
None yet
9 participants
@nikomatsakis
Copy link
Contributor

commented Nov 10, 2014

Just what it says in the subject.

Rendered view.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor Author

commented Nov 10, 2014

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

@Manishearth

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

Agree with this.

@Valloric

This comment has been minimized.

Copy link

commented Nov 10, 2014

👍 I've been bitten by this several times.

@TyOverby

This comment has been minimized.

Copy link

commented Nov 10, 2014

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

@huonw

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

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

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

@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

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

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

This comment has been minimized.

Copy link
Member

commented Nov 10, 2014

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

@blaenk

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2014

This is a great idea.

@bstrie

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2014

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

This comment has been minimized.

Copy link
Member

commented Nov 29, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.