-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Ambiguity in proposed pattern syntax #656
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
Comments
Graydon clarified on IRC that he intended type annotations for patterns to only occur at the top level of the pattern, not nested inside. That's probably just as powerful, and solves this problem. |
keeperofdakeys
pushed a commit
to keeperofdakeys/rust
that referenced
this issue
Dec 12, 2017
add missing socket constants Add some missing socket constants that are hardcoded by `nix` (nix-rust/nix#647) I took the opportunity to merge some constants in a upper module when applicable.
celinval
added a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
* Re-enable RMC to allow users to verify non-public main. Users don't usually set their main function to be public and we should enable them to verify their main function. For now, users will have to manually set the create type when running RMC directly. For cargo rmc, this should be automatically set up by cargo. * Update src/tools/dashboard/src/books.rs Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com> Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com>
GuillaumeGomez
pushed a commit
to GuillaumeGomez/rust
that referenced
this issue
May 14, 2025
Clean up docs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Colons will allow specifying the types of pattern elements (
let x: int = 6
), but are also used as separators between field names and sub-patterns in record patterns ({x: ?binding}
). Since we allow the sub-pattern to be omitted ({x}
is interpreted as{x: ?x}
) this introduces an ambiguity—the parser can't tell whether a colon in a record pattern indicates a sub-pattern or a type.Possible solutions include using another character for type assertions or simply specifying that the patterns has to be written out in full if you want to type it (resulting in the rather ugly
{x:?x:int}
).The text was updated successfully, but these errors were encountered: