Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
psionic12 opened this issue May 22, 2022 · 4 comments · Fixed by #97351
Closed

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

psionic12 opened this issue May 22, 2022 · 4 comments · Fixed by #97351
Labels
C-bug Category: This is a bug.

Comments

@psionic12
Copy link

psionic12 commented May 22, 2022

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
Copy link
Contributor

b-naber commented May 24, 2022

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
Copy link
Author

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
Copy link
Contributor

b-naber commented May 24, 2022

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
Copy link
Contributor

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.

@bors bors closed this as completed in 8a3ad49 May 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants