Skip to content
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

rustc doesn't seem to understand ~const bounds on associated types #88655

Open
Techcable opened this issue Sep 5, 2021 · 1 comment
Open
Labels
A-associated-items Area: Associated items (types, constants & functions) A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-trait-system Area: Trait system C-bug Category: This is a bug. F-const_trait_impl `#![feature(const_trait_impl)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Techcable
Copy link

Techcable commented Sep 5, 2021

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
@Techcable Techcable added the C-bug Category: This is a bug. label Sep 5, 2021
@camelid camelid added A-const-fn A-trait-system Area: Trait system F-const_trait_impl `#![feature(const_trait_impl)]` requires-nightly This issue requires a nightly compiler in some way. A-associated-items Area: Associated items (types, constants & functions) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 7, 2021
@fee1-dead
Copy link
Member

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.

@RalfJung RalfJung added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) and removed A-const-fn labels Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) A-trait-system Area: Trait system C-bug Category: This is a bug. F-const_trait_impl `#![feature(const_trait_impl)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants