Skip to content

match do catch-22 #44087

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
durka opened this issue Aug 25, 2017 · 8 comments
Closed

match do catch-22 #44087

durka opened this issue Aug 25, 2017 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@durka
Copy link
Contributor

durka commented Aug 25, 2017

It seems that you need to add parentheses in order to put a catch expression in a match head, but if you do, you get a warning:

#![feature(catch_expr)]

fn main() {
    match (do catch { }) { } //~WARN unnecessary parentheses around `match` head expression
    match do catch { } { } //~ERROR expected expression, found reserved keyword `do`
}

Why are the parens required anyway?

@kennytm
Copy link
Member

kennytm commented Aug 25, 2017

I think the original idea is to make this unambiguous? It was even checked in b1aa993.

let catch = 5;
match catch { ...

@durka
Copy link
Contributor Author

durka commented Aug 25, 2017

catch is already ambiguous with struct init syntax, I thought that's why we added do.

@shepmaster
Copy link
Member

catch is already ambiguous with struct init syntax,

But struct init syntax is disallowed in a match head.

@shepmaster shepmaster added A-catch C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 25, 2017
@durka
Copy link
Contributor Author

durka commented Aug 25, 2017

Then there's no ambiguity anyway. I don't understand the point of banning this. Maybe it's just been thrown in the large bin of "deal with this once we figure out how to get rid of do".

@durka
Copy link
Contributor Author

durka commented Oct 31, 2018

This somehow got even worse: now match (do catch {}) {} errors saying the new syntax is try, but obviously that doesn't compile either without enabling the new edition.

(And in E2018, match (try {}) {} still has a warning telling you remove parentheses that you can't remove.)

@kennytm kennytm added the A-diagnostics Area: Messages for errors, warnings, and lints label Oct 31, 2018
@kennytm
Copy link
Member

kennytm commented Oct 31, 2018

Given #54885 I'm labeling this a diagnostic problem.

@Mark-Simulacrum
Copy link
Member

Updated code, still lints on the unused parens but errors without them.

#![feature(try_blocks)]

fn main() {
    match (try { Ok::<_, ()>(0) }) {
        Ok(_) => {},
        Err(()) => {}
    }
}

@estebank estebank added the requires-nightly This issue requires a nightly compiler in some way. label Oct 15, 2019
@bjorn3
Copy link
Member

bjorn3 commented May 15, 2022

This now compiles:

#![feature(try_blocks)]

fn main() {
    match try { Ok::<_, ()>(0) } {
        Ok(_) => {},
        Err(()) => {}
    }
}

@bjorn3 bjorn3 closed this as completed May 15, 2022
@fmease fmease added F-try_blocks `#![feature(try_blocks)]` and removed A-catch labels Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants