Casting or adding type ascription to panic!() triggers unreachable_code

[leo60228]

fn test() -> impl Iterator<Item = i32> {
    panic!()
}

doesn't compile, as () (nor !) implement Iterator<Item = i32>.

#![feature(never_type_fallback)] // required for `panic!() as _`
fn test() -> impl Iterator<Item = i32> {
    panic!() as std::iter::Empty<_>
}

compiles, but gives this warning:

warning: unreachable expression
 --> src/lib.rs:3:5
  |
3 |     panic!() as std::iter::Empty<_>
  |     --------^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     unreachable expression
  |     any code following this expression is unreachable
  |
  = note: `#[warn(unreachable_code)]` on by default
  = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

#![feature(type_ascription)]
fn test() -> impl Iterator<Item = i32> {
    panic!(): std::iter::Empty<_>
}

also compiles, but gives the same warning.

[Centril]

Me and @jonas-schievink briefly discussed this on Discord.

It's not clear to me that this is a bug, but I could also see an argument for why coercions (through type ascription or via e.g. -> ReturnType { ... }) and possibly casts (as) would be treated specially as they "do nothing" (not entirely true, as casts and implicit coercions they may perform run-time work). As such, I'll relabel this as a language design question and if we agree that the behavior should change we can pass it back to the compiler team.

---

Particularly, we might consider coercions & casts different than e.g.

fn test() -> impl Iterator<Item = i32> {
    foo(
        panic!()
    )
}

fn foo(_: !) -> impl Iterator<Item = i32> { std::iter::empty() }

which results in:

warning: unreachable call
 --> src/lib.rs:2:5
  |
2 |     foo(
  |     ^^^ unreachable call
3 |         panic!()
  |         -------- any code following this expression is unreachable
  |
  = note: `#[warn(unreachable_code)]` on by default
  = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

[pnkfelix]

T-compiler triage: Leaving unprioritized for now while we wait to see what T-lang decides about whether this is a bug or not.

[Centril]

We discussed this very briefly in Thursday's language team meeting. Sadly, we did not have quorum to make any decisions. Mainly, I informed those present of the possible argument for a distinction wrt. casts and coercions as compared to e.g. function calls.

@leo60228 If possible, it would be good to elaborate on why we should add a special case to stop linting here and whether such complexity would be justified.

[leo60228]

I return unimplemented!() from all my WIP methods so I can cargo check while I'm writing them. I can't do this for a method returning impl Trait without triggering this lint.

[leo60228]

While I could just return std::iter::empty or similar, I think unimplemented!() expressed my intent much more clearly.

[pnkfelix]

While I am sympathetic to the annoyance of the lint here, this issue does not seem like a high priority issue for us to address.

triage: P-medium. Leaving nomination label so that we still try to discuss what to do next about it.

[Centril]

The language team discussed this today. Attendance was low, but we agreed that it would be OK to avoid linting in this case as it “makes sense because these expressions are useful for ensuring type inference succeeds”. This would apply to both type ascription and casts.