#[feature(exhaustive_patterns)] thinks irrefutable pattern is refutable when enum contains struct with private fields.

[BGR360]

The following code compiles on nightly (playground):

#![feature(exhaustive_patterns, never_type)]

enum Either<A, B> {
    A(A),
    B(Wrapper<B>),
}

struct Wrapper<T>(T);

fn foo() -> Either<(), !> {
    Either::A(())
}

fn main() {
    let Either::A(()) = foo();
}

But if the wrapper type is moved into a module to make the field private, then it does not: (playground):

#![feature(exhaustive_patterns, never_type)]

mod inner {
    pub struct Wrapper<T>(T);
}

enum Either<A, B> {
    A(A),
    B(inner::Wrapper<B>),
}

fn foo() -> Either<(), !> {
    Either::A(())
}

fn main() {
    let Either::A(()) = foo();
}

error[E0005]: refutable pattern in local binding: `Either::B(_)` not covered
  --> src/main.rs:17:9
   |
17 |     let Either::A(()) = foo();
   |         ^^^^^^^^^^^^^ pattern `Either::B(_)` not covered
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
   = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
note: `Either<(), !>` defined here
  --> src/main.rs:9:5
   |
7  | enum Either<A, B> {
   |      ------
8  |     A(A),
9  |     B(inner::Wrapper<B>),
   |     ^ not covered
   = note: the matched value is of type `Either<(), !>`
help: you might want to use `if let` to ignore the variant that isn't matched
   |
17 |     if let Either::A(()) = foo() { todo!() }
   |     ++                           ~~~~~~~~~~~

Making the field pub makes it compile again.

Is this expected? I suppose I could understand if it is; the private fields could change to make Wrapper<!> actually be constructable and therefore make the pattern refutable. But if that's the case, then I think the compiler should point this out, like note: the pattern is currently irrefutable, but the type contains private fields which may change in the future to make the pattern refutable.

If indeed this is expected, is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable? I want users of my library to be able to elide match arms when I give them an Either<A, !>.

@rustbot label +T-compiler +F-never_type +D-confusing +requires-nightly +S-bug-has-mcve

[BGR360]

@rustbot label +F-exhaustive_patterns

[BGR360]

@jackh726 are we sure this is actually a bug? As I said, I could understand how it's not:

Is this expected? I suppose I could understand if it is; the private fields could change to make Wrapper<!> actually be constructable and therefore make the pattern refutable.

[jackh726]

I'm not sure either way - however at the very least, as you point out, it makes sense to have some better diagnostics

[canndrew]

This is definitely intentional. But yeah, it should have a better error message.

is there any way for me as a library author to somehow convince the compiler that I will never change the fields to make the type constructable?

Not currently I don't think. It would probably require us to add an Uninhabited trait, eg. something like:

trait Uninhabited {
    fn uninhabited(self) -> !;
}

impl<T> Uninhabited for Wrapper<T>
where
    T: Uninhabited,
{
    fn uninhabited(self) -> ! {
        let Wrapper(inner) = self;
        match inner {}
    }
}

This trait would then need to be a lang item so that the exhaustiveness check could make use of it. Adding this trait would require an RFC but I doubt there'll be much enthusiasm for adding another special trait for such a niche use-case.

Alternatively, you could give Wrapper an into_inner or get_ref method to expose the uninhabitedness of the inner value. It's not quite what you're asking for but it's still concise-ish:

let a = match foo() {
    Either::A(a) => a,
    Either::B(wrapper) => match wrapper.get_ref() {},
};

[fmease]

Is Uninhabited::uninhabited supposed to be “injected” where an otherwise required match arm was omitted? Wouldn't that run into the same discussions project-deref-patterns had about impure code (code with side effects) inside patterns? Their existence would heavily hinder optimizations of match expressions (like translation to jump tables or reordering).

[canndrew]

If the type implementing Uninhabited really is uninhabited then there won't actually be any impure code in the match. The call to Uninhabited::uninhabited would only need to be injected for types that fake uninhabitedness with an impl that panics/aborts. We could also rule that out be instead making Uninhabited derive-only like Copy.

[Nadrieril]

Making Uninhabited a trait isn't straightforward exactly because inhabitedness depends on visibility questions. It would probably have to mean "Uninhabited as far as the outside world is concerned", or it could use a trick like the Context in safe transmute to make it depend on the module.