wart: non-Eq [T; 0] can be matched as if T were #[structural_match]

[pnkfelix]

Spawned off of investigation of issue #62307 and PR #55837

We currently allow constants that are empty arrays of any type to be used as patterns in match. We allow this regardless of whether they are an array of an ADT that does not derive PartialEq/Eq

This may be a feature or a bug depending on one's perspective.

Here is an example of the behavior in question (play):

struct B(i32);

const B0: [B; 0] = [];

//#[derive(PartialEq, Eq)] // can't uncomment b/c B doesn't impl PartialEq+Eq.
struct UhOh([B; 0]);

const _UH_OH: UhOh = UhOh(B0);

fn main() {
    match [] {
        B0 => { println!("B0 matched []"); }
    }

    match UhOh([]) {
        UhOh(B0) => { println!("UhOh(B0) matched UhOh([])"); }
    }

    #[cfg(this_wont_compile_without_derive_of_partial_eq_and_eq)]
    match UhOh([]) {
        _UH_OH => { println!("_UH_OH matched UhOh([]])"); }
    }
}

To be clear: This behavior might be fine.

It is just a little weird, because on other uses of consts in patterns, we do tend to require that their types derive PartialEq and Eq

• the use of the derive is asserted by the presence of #[structural_match]; see Restrict constants in patterns rfcs#1445).
• Update: there are other exceptions where PartialEq is not required for a const in a pattern, namely for for <'a> fn(&'a T); see Function pointer docs may need updating #46989 (comment) )

But we can treat an empty array as an exceptional case here, if that's what people want.

• If this is the behavior that we do want, then lets make sure we have a test encoding it.
• It this is not the behavior that we want, then we can fix it (presumably in a similar manner to how I am going about fixing issue structural_match bug: deep refs like & &B leak use of PartialEq #62307).

[pnkfelix]

nominating for discussion at T-lang team meeting, since this is a question about the design of the language itself.

(It may be worthwhile to try to make a PR that errors on such consts, e.g. rejecting the match [] { B0 => ... } in the example above, and then doing a crater run against that PR, to gather data on whether this is likely to occur in the wild.)

[pnkfelix]

A possibly interesting note: I think the reason this case wasn't caught was because of how this is written:

rust/src/librustc_mir/hair/pattern/mod.rs

Lines 1037 to 1045 in 8c6fb02

	ty::Array(_, n) => {
	PatternKind::Array {
	prefix: (0..n.unwrap_usize(self.tcx))
	.map(|i| adt_subpattern(i as usize, None))
	.collect(),
	slice: None,
	suffix: Vec::new(),
	}
	}

because we have layered the type-checking atop the recursion (encoded in the adt_subpattern closure), and there is no substructure to recur on when n=0.

I mainly note this because I'm curious if there's other checks on the contents' type in [T; n] that are skipped because of similar folding over 0..n.

[varkor]

This is consistent with special handling for zero-length arrays throughout the language. For instance, Default is implemented for zero-length arrays, even for types that themselves don't implement Default. (I think this is the right decision, but it does make some behaviour more complex.)

[Centril]

Further to @varkor's point, another case where LEN = 0 is "special" (or rather <= 1 is special for expected move-checking reasons) is the case of array repeat expressions, e.g.

struct NoCopy;
let x = [NoCopy; 0]; // OK.
let x = [NoCopy; 1]; // OK.
let x = [NoCopy; 2]; // ERROR.

[pnkfelix]

And yet the type [NoCopy; 0] is itself non-copyable... right? (play).

seems like something that's been decided in an ad hoc manner in each case, rather than having a consistent policy, no?

[Centril]

@pnkfelix A very good point! It seems pretty inconsistent indeed.

Might be good to do a survey if time allows. Ostensibly making [NoCopy; 0] Copy is the non-breaking change in "what direction should we move consistency in" discussion.

One further case in which [T; 0] is special is if is_uninhabited(T) holds and the corollary to this: [T; 0] is always a singleton type (if we assume totality under a sort of fast and loose reasoning).

[nikomatsakis]

Discussed briefly in the @rust-lang/lang meeting. We need to schedule some time to get into structural match. But, in the meantime, a useful step would be to do a crater run that tries to remove the [Foo; 0] case and see whether it has any effect.

[nikomatsakis]

I don't know @pnkfelix whether you'd have time to do that before you leave, but for anyone else who might have an interest, you could take a look at #62339 which adjusted this code and try to build a test PR from that.

[lcnr]

cc @RalfJung @oli-obk I think this issue can now be closed?

Afaict we now always need the type to implement PartialEq/Eq, even when inside of a zero-sized array, but it does not have to be derived. This is as any wrapper types for which we have a value need to derive PartialEq, meaning that its zero-length array field has to implement PartialEq.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b5239f44a96ae232228b5c9677390dbf

[RalfJung]

Indeed this should have been closed together with #120362. Empty arrays with element type T behave exactly like None::<T>: the type T must implement PartialEq, but it must not be derived, it can be a custom impl.