-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Conversation
Note: there was some (universally positive) discussion in a discuss thread already: http://discuss.rust-lang.org/t/preventing-lifetime-shadowing/784 |
Agree with this. |
👍 I've been bitten by this several times. |
This was my number 1 pain point when learning about lifetimes. |
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!()
} |
@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 Perhaps identifiers from macros should be visibly mangled in errors where this happens, or something? ( |
@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 |
Agreed; the RfC should explicitly mention that it's not going to change the pseudoshadowing that macros allow. |
This is a great idea. |
We had someone hit this just today in IRC. They had I already voiced my support in Discuss, but let me emphasize again that this would be a good change. |
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. |
Just what it says in the subject.
Rendered view.