Unable to match non_exhaustive enum tuple variants with rest pattern

[SpriteOvO]

Tuple enum variants Tuple(i32) from external crates marked with #[non_exhaustive] should be able to be matched by the RestPattern Tuple(val, ..). But it fails to compile.

I tried this code:

// In an external lib crate
#[non_exhaustive]
pub enum ExtNonExhaustiveVariant {
    ExhaustiveUnit,
    #[non_exhaustive]
    Unit,
    #[non_exhaustive]
    Tuple(i32),
    #[non_exhaustive]
    StructNoField {},
    #[non_exhaustive]
    Struct {
        field: i32,
    },
}

// In the bin crate
fn main() {
    match ExtNonExhaustiveVariant::ExhaustiveUnit {
        ExtNonExhaustiveVariant::ExhaustiveUnit => 0, // OK
        ExtNonExhaustiveVariant::Unit { .. } => 0, // OK
        ExtNonExhaustiveVariant::Tuple(val, ..) => val, // FAIL
        ExtNonExhaustiveVariant::StructNoField { .. } => 0, // OK
        ExtNonExhaustiveVariant::Struct { field, .. } => field, // OK
        _ => 0,
    };
}

I expected to see this happen: No compile error.

Instead, this happened:

error[E0603]: tuple variant `Tuple` is private
  --> src/main.rs:9:34
   |
9  |         ExtNonExhaustiveVariant::Tuple(val, ..) => val,
   |                                  ^^^^^ private tuple variant
   |
note: the tuple variant `Tuple` is defined here
  --> /repro/lib/src/lib.rs:14:5
   |
13 |     #[non_exhaustive]
   |     ----------------- cannot be constructed because it is `#[non_exhaustive]`
14 |     Tuple(i32),
   |     ^^^^^

For more information about this error, try `rustc --explain E0603`.
error: could not compile `bin` (bin "bin") due to 1 previous error

Meta

rustc --version --verbose:

rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-unknown-linux-gnu
release: 1.81.0
LLVM version: 18.1.7

[ehuss]

Thanks for the report! This behavior is (currently?) intentional. It has to do with privacy controls (you can read some of the gritty details in the RFC discussions at rust-lang/rfcs#2008). For now, you should be able to do ExtNonExhaustiveVariant::Tuple{0: val, ..}. Perhaps the diagnostics could suggest that?