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

Allow by-move binding for patterns with guards that don't reference the bindings #14252

Closed
kmcallister opened this issue May 16, 2014 · 3 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@kmcallister
Copy link
Contributor

I have

match token {
    DoctypeToken(dt) if mode == Initial => ...,
    DoctypeToken(dt) => ...,

    TagToken(x) => ...,
    CommentToken(x) => ...,
    // other cases

This gives

error: cannot bind by-move into a pattern guard

In this situation it should be fine to defer the move until the guard has succeeded.

It's a bit frivolous because I could instead do

match token {
    DoctypeToken(dt) => if mode == Initial {
        ...
    } else {
        ...
    },

    TagToken(x) => ...,
    CommentToken(x) => ...,
    // other cases

But I like having all the branching in one construct, especially when I'm implementing a spec which is written that way. And I don't want to add mode to the match scrutinee because none of the other cases care about it.

See also #4649.

@kmcallister kmcallister added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Sep 27, 2014
@steveklabnik
Copy link
Member

/cc @rust-lang/lang

@durka
Copy link
Contributor

durka commented Nov 26, 2015

Triage: still annoying.

edit: a more trivial (but quite related) enhancement is to not emit E0008 for pattern guards that don't move anything, let alone the captures. Example.

@huonw
Copy link
Member

huonw commented Jan 5, 2016

(Forward-)dupe of #15287, closing.

@huonw huonw closed this as completed Jan 5, 2016
lnicola pushed a commit to lnicola/rust that referenced this issue Mar 13, 2023
internal: Handle fields called as method calls as the fields they resolve to

Confusing PR title tbf but this makes it so `bar` in `foo.bar()` resolves to the field if it exists and no method with the same name exists. Improves UX slightly when incorrectly calling a field.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants