Skip to content

Allow arbitrary value to appear in pattern #1067

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

Closed
bombless opened this issue Apr 17, 2015 · 3 comments
Closed

Allow arbitrary value to appear in pattern #1067

bombless opened this issue Apr 17, 2015 · 3 comments
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@bombless
Copy link

For now you can only use const/static value in pattern, e.g.

let x = 0;
const MAGIC: i32 = 42;
match x {
    MAGIC => {}
    _ => {}
}

First, it's confusing that if MAGIC is not already defined as constant the matching will be a binding instead.
Second, if that MAGIC value cannot be determined at compile-time this will not work.

A workaround would be

#[derive(Eq, PartialEq)]
struct NonCopy;
match NonCopy {
    ref x if *x == NonCopy => {}
    _ => {}
}

Although it works, maybe we can do better.

There are 2 solutions I can imagine:

  • We cannot use block in pattern for now, so block syntax can be used here, which means
match NonCopy {
    {NonCopy} => {}
    _ => {}
}
  • @ inside pattern is limited, so this is also possible IMO:
match NonCopy {
    @NonCopy => {}
    _ => {}
}

Hopefully this proposal can solve #1059 in this way,

match pair {
    (x, @x) => {}
    _ => {}
}

but that will be another discussion.

EDIT: fix typo

@bombless
Copy link
Author

Due to the limitation of const/static values today, this will lead to new questions to answer.
I think @x => /* ... */ can be a sugar of ref y if *y == x => /* ... */ with y shadowed, I suggest we enforce an Eq comparation here, it is just sugar anyway.

@nagisa
Copy link
Member

nagisa commented Apr 17, 2015

This has an issue of making exhaustiveness check useless. I think match
should stay as it is currently.
On Apr 17, 2015 8:37 AM, "York Xiang" [email protected] wrote:

Due to the limitation of const/static values today, this will lead to new
questions to answer.
I think @x => /* ... / can be a sugar of ref y if *x == y => / ... */
with y shadowed, I suggest we enforce a Eq comparation here, it is just
sugar anyway.


Reply to this email directly or view it on GitHub
#1067 (comment).

@petrochenkov petrochenkov added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jan 30, 2018
@Centril
Copy link
Contributor

Centril commented Oct 15, 2018

Closing in favor of #263.

@Centril Centril closed this as completed Oct 15, 2018
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 RFC.
Projects
None yet
Development

No branches or pull requests

4 participants