Repository navigation
Closed as not planned
Closed as not planned
Copy link
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-trait-systemArea: Trait systemArea: Trait systemC-bugCategory: This is a bug.Category: This is a bug.F-const_trait_impl`#![feature(const_trait_impl)]``#![feature(const_trait_impl)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Description
I tried this code (playground]:
#![feature(const_trait_impl, const_fn_trait_bound)]
pub trait ConstableTrait {
fn foo(&self) -> u32;
}
pub trait ExTrait {
type Assoc: ~const ConstableTrait;
}
struct ShouldBeInferred<T: ExTrait> {
a: T::Assoc
}
impl<T: ExTrait> ShouldBeInferred<T> {
pub const fn should_infer(&self) -> u32 {
self.a.foo()
}
}I expected to see this happen:
ShouldBeInferred::should_infer should understand that T::AssocTrait: ~const ConstableTrait and self.a.foo() is a const-fn.
Instead, this happened:
The compiler doesn't seem to infer the T::AssocTrait: ~const ConstableTrait bound gives an error self.a.foo() is not callable in a constant context.
I might be misunderstanding the purpose of ~const bounds on associated types. Please correct me if I am :)
Also great work so far on const fn. It's really starting to shine :)
Meta
rustc --version --verbose:
rustc 1.56.0-nightly (b7404c898 2021-09-03)
binary: rustc
commit-hash: b7404c898a1a6933b71c72428a6dce551bcc1be7
commit-date: 2021-09-03
host: x86_64-unknown-linux-gnu
release: 1.56.0-nightly
LLVM version: 13.0.0
Metadata
Metadata
Assignees
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-trait-systemArea: Trait systemArea: Trait systemC-bugCategory: This is a bug.Category: This is a bug.F-const_trait_impl`#![feature(const_trait_impl)]``#![feature(const_trait_impl)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Activity
fee1-dead commentedon Sep 9, 2021
With the change to
~const, these implicitness have been removed. So you can't rely on the inherent impl method being const, to assume that the impl's bounds are all inferred to be~const.And currently I don't think it is possible to achieve what you want. But the ideal solution is to use where clauses on the const fn and bound
T: ~const ExTrait. See also #88424, and we will allow these where clauses on const fns on inherent impls once we land #88558.nxsaken commentedon Nov 16, 2025
Seems to be a problem still:
fee1-dead commentedon Nov 16, 2025
@nxsaken The generated code from the derive never makes a
T: [const] Traitbound: (play)And
[const]is only implied via[const]bounds. If you want it to always be applicable, usetype Type: Copy + const Clone, or useT: [const] Traiton a manual implfee1-dead commentedon Nov 16, 2025
Closing the original issue as won't fix.
T::Assoccan be assumed to have[const] ConstableTraitif we haveT: [const] ExTrait. The original code snippet does not haveT: [const] ExTraitso this cannot be assumed.To fix: either use
type Assoc: const ConstableTraitalways const bound on the assoc, or boundT: [const] ExTrait.