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.