Skip to content

[adt_const_params] consider to avoid using specialization when implement traits for Foo<const B: Bar> #130799

@psionic12

Description

@psionic12

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)

Activity

changed the title [-][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>[/+] on Jan 5, 2024
fmease

fmease commented on Jan 6, 2024

@fmease
Member

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.

added
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Sep 24, 2024
added
T-typesRelevant to the types team, which will review and decide on the PR/issue.
and removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on Sep 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    F-adt_const_params`#![feature(adt_const_params)]`T-typesRelevant to the types team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Enselic@psionic12@saethlin@fmease@rustbot

        Issue actions

          [adt_const_params] consider to avoid using specialization when implement traits for Foo<const B: Bar> · Issue #130799 · rust-lang/rust