[feature(adt_const_params)] `Bar` doesn't derive both `PartialEq` and `Eq`

[psionic12]

I'v read the issue and the issue, and it seems that neither is my case.

rust version: rustc 1.62.0-nightly (a707f40 2022-04-29)

I tried this code:

#![feature(adt_const_params)]

use std::sync::Arc;

#[derive(PartialEq, Eq)]
enum Bar {
    Bar(Arc<i32>)
}

fn test<const BAR: Bar>() {}

I expected to see this the code to be compiled, but it's not:

error[E0741]: `Bar` must be annotated with `#[derive(PartialEq, Eq)]` to be used as the type of a const parameter
  --> src\main.rs:16:20
   |
16 | fn test<const BAR: Bar>() {}
   |                    ^^^ `Bar` doesn't derive both `PartialEq` and `Eq`

My guess is that the type Arc doesn't implement StructuralPartialEq, and I tried to use the feature newtype to wrap around the Arc, but still not working

So is it a bug or is there some limitations? Is there anyway I can make my code compile?

[b-naber]

Yeah the reason why this doesn't compile is that Arc doesn't implement StructuralPartialEq. Tried to make the error message somewhat less confusing.

[psionic12]

May I ask why StructuralPartialEq is a necessary in the feature adt_const_params?
IIRC, StructuralPartialEq is used for performance and flexibility (for example, a type does not implement PartailEq, but all its fields do). A type implemented with PartialEq and Eq is comparable, which seems enough for the feature adt_const_params

[b-naber]

My understanding is that StructuralPartialEq was introduced to ensure that pattern matching on constants works correctly. A constant is structurally equal to another constant if their fields are structurally equal, where primitive types are structurally equal if they represent the same value. Note that if you derive PartialEq you get exactly that, structural equality, whereas if you manually implement PartialEq you don't necessarily get that (depending on your impl). There's more information in RFC 1445.

I'm not entirely sure, but I think this might all change once we introduce ValTrees (a new type-system representation for constant values) and are able to use them in pattern matching.

[clarfonthey]

StructuralPartialEq is basically required for any reasonable implementation of const generics, since it essentially lets the compiler treat the constants as opaque bit strings, which makes for easy table lookups, etc.

There's also the additional security implications where, if this weren't the case, the compiler would have to run any crate's code for arbitrary constants, whereas right now, crate code is only run directly for build scripts and proc macros. Even if we changed from StructuralPartialEq to some other trait like Hash or Ord, the problem of running crate code would still exist.