Borrow checker does not recognize direct-call of try operator (i.e., `Err()?`), causing reporting of `use of moved value`

[KShChan]

Code

fn foo_tasks() -> Vec<impl Future<Output = Result<i32, ()>>> { /*... logical stuffs ...*/ } 

let async_tasks = foo_tasks();
if upper_condi {
    let task_results_upper = try_join_all(async_tasks).await?;
    // ...
    Err(())?;
}
if lower_condi {
    let task_results_lower = try_join_all(async_tasks).await?;
    // ...
    Err(())?;
}

Current output

error[E0382]: use of moved value: `async_tasks`

| let async_tasks = foo_tasks();
|     ----------- move occurs because `async_tasks` has type `Vec<impl Future<Output = Result<i32, ()>>>`, which does not implement the `Copy` trait
...
| 
| let task_results_upper = try_join_all(async_tasks).await?;
                                        ----------- value moved here
...
| let task_results_lower = try_join_all(async_tasks).await?;
|                                       ^^^^^^^^^^^ value used here after move

Desired output

Rationale and extra context

No response

Other cases

Rust Version

$ rustc --version --verbose
rustc 1.94.0 (4a4ef493e 2026-03-02)
binary: rustc
commit-hash: 4a4ef493e3a1488c6e321570238084b38948f6db
commit-date: 2026-03-02
host: x86_64-unknown-linux-gnu
release: 1.94.0
LLVM version: 21.1.8

Anything else?

I expect putting ? directly on Err() can do a short-circuit to the current function so that receiving a smoother programming experience. Directly putting ? on Err() reaching for quick leave demonstrates that I know what I am doing, which this operation is indeed logical, but the actual compiler implementation apply the match { ... } to ?-operator.

I can fixed this rustc error by replacing Err(())? into return Err(()) in my project, but I create this issue for letting rustc team recognizing this logical issue for imrpovement.

[mathisbot]

A smaller example that shows the same issue is:

struct NotCopy;
fn cond() -> bool { /* irrelevant */ }

fn main() -> Result<(), ()> {
    let x = NotCopy;

    if cond() {
        drop(x);
        Err(())?;
    }

    drop(x); // error: use of moved value
    Ok(())
}

My understanding is that this comes from how the borrow checker reasons about control flow. It has to validate all possible paths through the program.

The ? operator goes through the Try machinery and desugars to something equivalent to:

match Try::branch(Err(())) {
    ControlFlow::Continue(v) => v,
    ControlFlow::Break(e) => return Err(e.into()),
}

From the borrow checker's perspective, both branches have to be considered possible, even if in this specific case you know that Err(()) will always take the return path.

The ? operator works with any type implementing Try, not just Result.
So the compiler cannot bake in knowledge like "Err(_) always returns" without breaking that abstraction.

Even if it tried to special-case Result, you'd immediately run into inconsistencies with equivalent code written slightly differently.
For example, if you wrap the error in a function:

fn err() -> Result<(), ()> { Err(()) }

fn main() -> Result<(), ()> {
    let x = NotCopy;

    if cond() {
        drop(x);
        err()?;
    }

    drop(x); // error: use of moved value
    Ok(())
}

this is logically the same as Err(())?, but now the compiler would have to understand what err() does to make the same decision.

It also feels like it could lead to surprising inconsistencies.
If Err(())? compiled but err()? didn't, or if a small refactor suddenly introduced a borrow checker error somewhere else, that would be pretty surprising and hard to reason about.