Skip to content

Semicolon after diverging try operator shouldn't matter #106357

Open
@clarfonthey

Description

@clarfonthey
Contributor

Originally mentioned in this comment: #96373 (comment)

Essentially, semicolons after other diverging expressions are allowed. For example:

fn works() -> Result<bool, i32> {
    return Err(1);
}

Here, the compiler is clever enough to note that because return Err(1) always diverges, adding a semicolon after doesn't matter. However, the below code which is equivalent to this does not work properly:

fn breaks() -> Result<bool, i32> {
    Err(1)?;
}

Here's a playground link containing the above two examples: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=af894bab48348897a421a9402856b71f

The exact compiler error:

error[[E0308]](https://doc.rust-lang.org/nightly/error-index.html#E0308): mismatched types
 --> src/lib.rs:5:16
  |
5 | fn breaks() -> Result<bool, i32> {
  |    ------      ^^^^^^^^^^^^^^^^^ expected enum `Result`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
6 |     Err(1)?;
  |            - help: remove this semicolon to return this value
  |
  = note:   expected enum `Result<bool, i32>`
          found unit type `()`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `playground` due to previous error

Activity

andersk

andersk commented on Jan 1, 2023

@andersk
Contributor

My understanding is that this is related to the fallback issues that have been preventing stabilization of the ! type. See

clarfonthey

clarfonthey commented on Jan 2, 2023

@clarfonthey
ContributorAuthor

I was kind of afraid that's the case.

If this seems too separate from the existing issues for those, feel free to close it! Although I guess that this is another example that might be useful to test for.

aDotInTheVoid

aDotInTheVoid commented on Jan 2, 2023

@aDotInTheVoid
Member

I'm not sure this is a bug,

fn breaks() -> Result<bool, i32> {
    Err(1)?;
}

gets desugared to

fn breaks() -> Result<bool, i32> {
    match Err(1) {
         Ok(x) => x,
         Err(e) => return Err(e.into())
    };
}

Unless you are relying on the compiler to eliminate the Ok branch as unreachable, which isn't guaranteed to happen, the whole expression isn't diverging (in the mind of the type system).

I don't think the compiler should be required to do this elimination, as involving optimizations in exausiveness checks seems like it could get unintuitive fast, and expose many people to accidental breakage.

added
T-typesRelevant to the types team, which will review and decide on the PR/issue.
on Jan 2, 2023
clarfonthey

clarfonthey commented on Jan 2, 2023

@clarfonthey
ContributorAuthor

So, I would agree with this, except for the fact that the compiler could absolutely infer the type of Err(1) to be Result<!, i32> and thus treat the Ok branch as diverging. But that leads into the ! fallback problems that were mentioned.

est31

est31 commented on Jan 4, 2023

@est31
Member
kadiwa4

kadiwa4 commented on Jan 5, 2023

@kadiwa4
Contributor

Also related: feature exhaustive_patterns #51085

WaffleLapkin

WaffleLapkin commented on Jun 13, 2024

@WaffleLapkin
Member

So. Mrgh. This issue is indeed with the fallback.

fn breaks() -> Result<bool, i32> {
    match Err(1) {
         Ok(x) => x,
         Err(e) => return Err(e.into())
    };
}

This desugaring causes the type of the match to be inferred to (), due to the fallback issue. I would expect that this will start "working" in 2024 edition.

Note however that I would highly advice against writing Err(x)?. The type of Ok variant should no be inferred from the ?. IMO it's a bug in ?'s desugaring. Similarly, allowing ; after diverging expressions is somewhat confusing. I was discussing with T-lang if we can break both of those things, but it did not cut the 2024 edition (and not yet decided that we actually want to break these things).

added
C-discussionCategory: Discussion or questions that doesn't represent real issues.
and removed
C-bugCategory: This is a bug.
on Jun 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-discussionCategory: Discussion or questions that doesn't represent real issues.F-never_type`#![feature(never_type)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @andersk@Enselic@traviscross@est31@clarfonthey

        Issue actions

          Semicolon after diverging try operator shouldn't matter · Issue #106357 · rust-lang/rust