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

Foo(..) patterns work for tuple structs, but (..) doesn't work for tuples #31443

Closed
niconii opened this issue Feb 6, 2016 · 4 comments
Closed
Labels
T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@niconii
Copy link
Contributor

niconii commented Feb 6, 2016

Right now, this compiles:

struct Foo(i32, i32, i32);

fn main() {
    match Foo(1, 2, 3) {
        Foo(..) => { }
    }
}

but this fails to compile:

fn main() {
    match (1, 2, 3) {
        // must write `(_, _, _) => { }`
        (..) => { }
    }
}
@petrochenkov
Copy link
Contributor

Yeah, also

struct Foo(i32, i32, i32);

fn main() {
    match Foo(1, 2, 3) {
        Foo(a, ..) => { }
    }
}

doesn't work. .. in patterns has a couple of pretty obvious extensions, someone just need to write an RFC (probably me, at least I was going to do it some time ago).

@durka
Copy link
Contributor

durka commented Feb 6, 2016

@petrochenkov have to be careful because in

struct Foo(i32, RangeFull);

fn main() {
    match Foo(i32, ..) {
        Foo(a, ..) => { }
    }
}

the .. is not a catchall pattern. So the extensions may lead to confusion/ambiguity. I guess this is already a problem with struct Foo(RangeFull);.

@petrochenkov
Copy link
Contributor

@durka
RangeFull literals .. are not considered patterns, so there's no conflict currently.

@steveklabnik
Copy link
Member

Closing in favor of the RFC, since this would be a language change.

@steveklabnik steveklabnik added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants