-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
F-adt_const_params`#![feature(adt_const_params)]``#![feature(adt_const_params)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Description
Not sure this should be a lacking in RFC or a bug in compiler, sorry if I issued to the wrong place.
The title is a little confusing, here is an exmple for illustating:
#![feature(adt_const_params)]
#[derive(PartialEq, Eq, ConstParamTy)]
enum Number {
Int,
Float,
}
struct PropWrapper<const N: Number> {}
trait Prop {
type Ty;
}
impl Prop for PropWrapper<{Number::Int }> {
type Ty = usize;
}
impl Prop for PropWrapper<{Number::Float }> {
type Ty = f32;
}
struct Foo<const N: Number> {
n: <PropWrapper<N> as Prop>::Ty,
}
As you can see, I listed all the possible trait implementations Prop
for types of PropWrapper
(in this case, two possible types), but the compiler still complains:
error[E0277]: the trait bound `PropWrapper<N>: Prop` is not satisfied
--> src/main.rs:29:8
|
29 | n: <PropWrapper<N> as Prop>::Ty,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Prop` is not implemented for `PropWrapper<N>`
|
= help: the following other types implement trait `Prop`:
PropWrapper<Number::Float>
PropWrapper<Number::Int>
Currently my workaround is to use specialization:
impl<const N: Number> Prop for PropWrapper<N> {
default type Ty = ();
}
This is unnecessary and the default case will never hit.
Is it reasonable for the compiler to check if all possible implementations are all listed for the case of using adt_const_params
?
I use the nigthly build rustc 1.77.0-nightly (f688dd6 2024-01-04)
SOF3
Metadata
Metadata
Assignees
Labels
F-adt_const_params`#![feature(adt_const_params)]``#![feature(adt_const_params)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
[-][adt_const_params] consider avoid specialization when implement traits for Foo<const B: Bar>[/-][+][adt_const_params] consider to avoid using specialization when implement traits for Foo<const B: Bar>[/+]fmease commentedon Jan 6, 2024
Thanks for your report! We are definitely aware of this shortcoming, see also rust-lang/project-const-generics#26 (for const params, i.e., your specific problem) and #103292 (for assoc const equality bounds).
It's not easy to implement, check out this Zulip comment of mine. Or this Zulip comment by lcnr.
Similar to assoc const equality bounds, assoc type equality bounds exhibit a related problem at the moment: #20400 and closed/postponed RFC rust-lang/rfcs#1672.