`Foo<T>: Trait` bounds (`T` is a type param) are allowed in `const fn`s

[rodrimati1992]

I tried this code:

pub trait Const {
    const C: u8;
}

impl Const for u8 {
    const C: u8 = 3;
}
pub struct Wrapper<T>(T);
impl<T: Const> Const for Wrapper<T> {
    const C: u8 = T::C;
}

const fn foo<T>() -> u8 
where
    Wrapper<T>: Const,
{
    <Wrapper<T>>::C
}

fn main(){
    const D: u8 = foo::<u8>();
    dbg!(D);
}

I expected to see this code not compile, because it bounds types by non-auto traits in const fns.

Instead, this happened: The code compiles without errors, and prints 3
This does error with T: Const bounds as expected.

Meta

rustc --version --verbose:

rustc 1.53.0-nightly (673d0db5e 2021-03-23)
binary: rustc
commit-hash: 673d0db5e393e9c64897005b470bfeb6d5aec61b
commit-date: 2021-03-23
host: i686-unknown-linux-gnu
release: 1.53.0-nightly
LLVM version: 12.0.0

[slightlyoutofphase]

It's not clear to me why this would be expected not to work. The bounds are upheld correctly by the compiler in precisely the same way as they are for non-const fns. For example if you do const D: usize = foo::<usize>();, you properly get error[E0277]: the trait bound usize: Const is not satisfied.

Same thing if you call foo in a runtime context, like let d: usize = foo::<usize>();, since every const fn is also by default a regular fn if called in a non-const context. I cannot personally think of any "upsides" of the particular trait bound restriction on const fns you're talking about actually existing.

[rodrimati1992]

@slightlyoutofphase That's an argument for allowing all bounds in const fns

If you look at what's proposed in https://github.com/oli-obk/rfcs/blob/const_generic_const_fn_bounds/text/0000-const-generic-const-fn-bounds.md#guide-level-explanation . The foo function (from my example) will require Const to be implemented as impl const Const for u8 and impl<T: Const> const Const for Wrapper<T> when foo is used in a const context, that will break this example.

[slightlyoutofphase]

@slightlyoutofphase That's an argument for allowing all bounds in const fns

I guess my overall point is that I'm not personally aware of anywhere it's been specifically stated that this shouldn't work, and why it shouldn't work.

If you look at what's proposed in https://github.com/oli-obk/rfcs/blob/const_generic_const_fn_bounds/text/0000-const-generic-const-fn-bounds.md#guide-level-explanation . The foo function (from my example) will require Const to be implemented as impl const Const for u8 and impl<T: Const> const Const for Wrapper<T> when foo is used in a const context, that will break this example.

Your Const trait has no methods though. There is no reason for it to need to be implemented specifically as const.

[rodrimati1992]

Your Const trait has no methods though

It doesn't matter, you're allowed to add defaulted methods and that shouldn't break downstream users, which is why impl const Const needs to be required.

This is not the issue to figure out how to solve problems with const trait impls and bounds though, it's about making sure that there's no forward compatibility bugs.

This isn't allowed now:

const fn foo<T: Const>() -> u8 {
    T::C
}

and I see no reason why it should be any different with Foo<T>: Const

[slightlyoutofphase]

It doesn't matter, you're allowed to add defaulted methods and that shouldn't break downstream users, which is why impl const Const needs to be required.

It doesn't need to be "required". The only limitation currently is that a user cannot directly write:

fn foo<T: const Const>()

meaning T has to specifically be something that implements Const as const. However, as far as I'm aware, some way of writing that (even if not with the exact syntax I just used) is planned, but just not implemented yet.

This isn't allowed now:

Yeah it is, if you use the #![feature(const_fn)] flag. Which anyone trying to do anything complex with const fn functionality specifically on the nightly compiler will be.

[jonas-schievink]

The problem is that the code posted above is accepted on stable, but the intention of the const_trait_impl feature is that all trait bounds on const fns will require an impl const Trait, unless you use T: ?const Trait syntax to opt out, which would cause the code to no longer be accepted.

[slightlyoutofphase]

The problem is that the code posted above is accepted on stable, but the intention of the const_trait_impl feature is that all trait bounds on const fns will require an impl const Trait, unless you use T: ?const Trait syntax to opt out, which would cause the code to no longer be accepted.

This makes much more sense if they're specifically talking about stable, where literally no feature flags can be used (meaning const_trait_impl and numerous other things don't actually exist there currently). They stated that they're using nightly in the initial comment, though, which is what I was going off of.

Edit: Actually, I'm not sure the "blanket requirement" interpretation of what is meant in the RFC is entirely correct. The way it works now, if actually using const_trait_impl, is like this:

#![allow(incomplete_features, dead_code)]
#![feature(const_fn, const_trait_impl)]

pub trait Const {
    const ONE: usize = 1usize;
    fn one() -> Self;
}

impl const Const for u8 {
    fn one() -> u8 {
        1u8
    }
}

impl Const for usize {
    fn one() -> usize {
        1usize
    }
}

const fn foo1<T: Const>() -> usize {
    T::ONE
}

const fn foo2<T: Const>() -> T {
    T::one()
}

fn main() {
    // `foo1` explicitly returns `1usize` no matter what, so the `constness` of T's
    // `Const` trait impl is completely irrelevant.
    const X: usize = foo1::<u8>();
    const Y: usize = foo1::<usize>();
    // `u8` did `impl const Const`, so the next line works with `foo2`.
    const Z: u8 = foo2::<u8>();
    // `usize` just did `impl Const`, so the next line does not work with `foo2`.
    const W: usize = foo2::<usize>();
}

Playground link.

Which is to say, in the context of a const fn that neither explicitly "opts-in" or "opts-out" to / of a trait bound specifically needing to be implemented as const by T, the constness of the impl is irrelevant unless the code actually uses it in a way that makes it relevant (i.e. by calling an actual function, as opposed to using an integral constant that is, well, an integral constant).

The only requirements for associated anything the RFC mentions is the requirement for associated types to also have const impls while actually implementing a given trait as const.

[rodrimati1992]

@slightlyoutofphase The code isn't using any features at all(so it shouldn't matter that my initial comment used nightly), and yes this works on stable in every version I tried back to Rust 1.31.0 https://rust.godbolt.org/z/7TnxfPP3W

The only reason I mentioned that I'm using nightly is to make it obvious that this wasn't fixed by a recent PR.

Please don't assume that using nightly means that I must want to use any or all nightly features.

[slightlyoutofphase]

@slightlyoutofphase The code isn't using any features at all(so it shouldn't matter that my initial comment used nightly), and yes this works on stable in every version I tried back to Rust 1.31.0 https://rust.godbolt.org/z/7TnxfPP3W

I still don't understand how there's any kind of "forward compatibility" concern. You cannot write const fn code on stable that relies on anything related to const_trait_impl in a way that could be broken by the compiler in the future, because you cannot actually implement traits as const on stable or call the methods of any trait in a const fn on stable.

Your original example could only be broken if the maintainer of the Wrapper crate went ahead and changed the associated C constant to something completely different, which would be a breaking change entirely on their part that isn't really related to const_fn or const_trait_impl at all. An associated constant u8 is just like any other valid constant in Rust.

[rodrimati1992]

I still don't understand how there's any kind of "forward compatibility" concern.

SImple, the code compiles now, and it'll break whenever const impls and bounds are fully implemented.

It''ll be required to be a const Const impl in the const D: u8 = foo::<u8>(); line, and the error will be "Expected implementation of const Const for Wrapper<u8>, found (non-const)Const impl"

I repeat, no code at all in #83452 (comment) needs to change for that to break.

Also, there is no code around that, it's the only code you need in a main.rs file in a project that only depends on std, only the compiler changes here, and no nightly features at all.

[slightlyoutofphase]

It''ll be required to be a const Const impl in the const D: u8 = foo::<u8>(); line, and the error will be "Expected implementation of const Const for Wrapper<u8>, found (non-const)Const impl"

Again, my point is that it's not clear to me that this is actually the case for something that strictly involves nameable integral constants with known primitive types. It doesn't make any sense, and has none of the same actual stability concerns that calling const trait methods (which you cannot do currently on stable) does.

Consider something like the following, also, that does work on stable today as well:

trait Trait {
    const F: usize = 99;
}

struct X;

impl Trait for X {}

const fn foo() -> usize {
    X::F
}

What it actually does is ultimately the same thing as your example. It's just accessing the constant indirectly. Which is fine, because if someone changes F or removes F from Trait entirely it'd be equally as breaking of a change in both const and runtime contexts.

Look at the playground link I posted earlier, also. The way it's been made to work so far is logical and provides really good error reporting. Intentionally "dumbing it down" in the particular way you're suggesting would be very strange IMO.