ConstParamTy: require Eq as supertrait by RalfJung · Pull Request #116125 · rust...
source link: https://github.com/rust-lang/rust/pull/116125
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
require Eq as supertrait by RalfJung · Pull Request #116125 · rust-lang/rust · GitHub
Member
As discussed with @BoxyUwU on Zulip.
We want to say that valtree equality on const generic params agrees with ==, but that only makes sense if == actually exists, hence we should have an appropriate bound. Valtree equality is an equivalence relation, so such a type can always be Eq and not just PartialEq.
Collaborator
|
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
labels
| @@ -986,11 +986,16 @@ pub trait Tuple {} | ||
pub trait PointerLike {} |
||
/// A marker for types which can be used as types of `const` generic parameters. |
||
/// |
||
/// These types must have a proper equivalence relation (`Eq`) and it must be automatically |
Is this "just in case"? Like, there are no types that implement StructuralEq that don't also implement Eq, right, at least without a manual StructuralEq impl?
Would be nice if you could add a test showing where possibly dubious code goes from pass -> err.
Member
Author
Like, there are no types that implement StructuralEq that don't also implement Eq, right, at least without a manual StructuralEq impl?
Not quite.
A generic type with derive(Eq) will implement StructuralEq without any bounds on the generic parameters.
Is this "just in case"?
This is mostly to make the 2nd half of the comment coherent: we want to say that valtree equality agrees with ==. Without at least a PartialEq bound, that statement is ill-formed, since the type might not even have ==.
Member
Author
Would be nice if you could add a test showing where possibly dubious code goes from pass -> err.
I don't know any such test (without a manual StructualEq impl), but currently the invariants that achieve that ConstParamTy implies Eq are rather subtle. This makes them a lot more obvious.
currently the invariants that achieve that ConstParamTy implies Eq are rather subtle. This makes them a lot more obvious.
Yeah, ok, that's all I wanted to really know. This isn't necessarily for "correctness" (but perhaps only by accident do we imply the right thing due to recursively checking fields for ConstParamTy in impls).
Member
Author
I also view this as preparation for removing the StructuralEq trait entirely (at which point only the StructuralPartialEq bound would be left otherwise).
I can do that all in the same PR if you prefer.
Nah, I'll probably have more questions about behavioral changes on that PR anyways 😅
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK