-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tuple struct/variant patterns don't work with type aliases #31659
Comments
I agree with the current behavior. The way I see it, tuple struct constructors live in the value namespace and these constructors can be used as functions or as patterns. I think it would be confusing to have fn Some(x: i32) -> Option<i32> { Some(1) }
fn main() {
let x = 0;
match Some(x) {
Some(x) => println!("{}", x), // This would print "1"
_ => {}
}
} |
There is a philosophy in Rust that deconstruction by patterns matches construction. I think that supports the notion that the pattern is the constructor function 'in reverse' rather than the type. Can we contrive an example with structs where the struct name is hidden in the type namespace but not the value namespace, and then what happens to the pattern? Does it still work? As long as we are consistent, then I think it is better to leave things as they are, rather than change the rules. |
Yeah, and the pattern still works: mod foo {
mod bar {
pub struct Bar(pub i32);
}
pub use self::bar::Bar;
}
use foo::*;
struct Bar { u: () }
fn main() {
match Bar(0) {
Bar(x) => println!("{}", x), // prints "0"
}
} |
Probably related to #26264 |
Given the drawbacks/interpretations given above I'm not sure this change would be better than status quo anymore. |
For some reason names of tuple struct/variant patterns are searched for in the value namespace and not in the type namespace.
This is strange, because
S
here is a name of the type, not constructor function, andS(x)
is not a function call.S
andZ
should probably be searched in the type namespace, like names of struct patternsS{..}
.Theoretically such change can break code, but only in highly contrived cases.
@jseyfried @nrc what do you think?
The text was updated successfully, but these errors were encountered: