-
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
Implement ..
in tuple (struct) patterns (RFC 1492)
#33639
Conversation
Since this implements an RfC, it will need to land soon, right? In that case, we probably should make a batch soon after this gets approved -- so if you have other PRs you want to make, now is the time! |
☔ The latest upstream changes (presumably #33654) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased. |
/// "None" means a `Variant(..)` pattern where we don't bind the fields to names. | ||
TupleStruct(Path, Option<HirVec<P<Pat>>>), | ||
/// A tuple struct/variant pattern `Variant(x, y, .., z)`. | ||
/// If the `..` pattern fragment presents, then `Option<usize>` denotes its position. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: s/presents/is present/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that there is anything wrong with it, but I am surprised by this choice; I would have expected Vec<P<Pat>>
and Option<Vec<P<Pat>>>
, where the second set of patterns come after the ..
. Did you consider this and find that the current optional usize works out better (or just that you prefer it)? Anyway, it seems ok as is, just wanted to toss an alternative out there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One allocation, the variant itself is more compact (6 ptrs vs 4 ptrs), simpler traversal (no vec1.chain(vec2)
).
Looks good. r=me with the add'l tests listed and nits addressed, though we should decide whether |
Updated. |
My vote: let's keep it illegal and thereby start conservatively. |
I concur with @aturon; plus both syntaxes are feature gated so even if change wasn't a conservative extension we would still be within bounds to change it later |
OK. Seems weird to me to permit trailing commas but only sometimes, but I bow to the will of the masses! |
@bors r+ |
📌 Commit 4983025 has been approved by |
D'oh, sorry @Manishearth
|
cc rust-lang#33627 r? @nikomatsakis plugin-[breaking-change] cc rust-lang#31645 @Manishearth
cc rust-lang#33627 r? @nikomatsakis plugin-[breaking-change] cc rust-lang#31645 @Manishearth
cc #33627
r? @nikomatsakis
plugin-[breaking-change] cc #31645 @Manishearth