You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now you can only use const/static value in pattern, e.g.
let x = 0;constMAGIC: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)]structNonCopy;matchNonCopy{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
matchNonCopy{{NonCopy} => {}
_ => {}}
@ inside pattern is limited, so this is also possible IMO:
matchNonCopy{
@NonCopy => {}
_ => {}}
Hopefully this proposal can solve #1059 in this way,
match pair {(x, @x) => {}
_ => {}}
but that will be another discussion.
EDIT: fix typo
The text was updated successfully, but these errors were encountered:
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.
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).
For now you can only use const/static value in pattern, e.g.
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
Although it works, maybe we can do better.
There are 2 solutions I can imagine:
@
inside pattern is limited, so this is also possible IMO:Hopefully this proposal can solve #1059 in this way,
but that will be another discussion.
EDIT: fix typo
The text was updated successfully, but these errors were encountered: