Document that associated constants prevent a trait from being made into an object

[Badel2]

Fixes #47952

Add a short mention of associated constants to E0038

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[Badel2]

I would love to add why exactly they are not allowed, but I couldn't find the reason. Relevant issues: #29646 #26847

[Havvy]

The reason is that because the trait object implements the trait too, and what would the constant be for that trait object? E.g. given a trait Trait with an associated constant CONST of type i32, what would this mean?

fn takes_trait_obj(t: &dyn Trait) -> i32 { <dyn Trait>::CONST }

Or as another (I think it was @eddyb?) said on IRC, a constant is effectively a no-argument static (const) function, and static functions aren't allowed for the same reason.

[eddyb]

r? @nikomatsakis

[nikomatsakis]

@Badel2 did @Havvy's explanation make sense to you? Would you like to try updating to include more background on why it is not allowed?

[Badel2]

The explaination makes sense, especially when compared to static functions. It's a shame you can't add where Self: Sized to constants. I will move this error just below the static functions one, and add "Just like static functions, associated constants aren't stored on the method table".

[nikomatsakis]

@Badel2 once the GAT work is fully done, we can probably support that, actually (where Self: Sized)

[nikomatsakis]

@bors r+ rollup

[bors]

📌 Commit 498ef20 has been approved by nikomatsakis

[eddyb]

Wait, why does where Self: Sized not work? Is it just syntactical? I'd fully expect to (I don't see GAT would be relevant - even if we supported generic constants, they're like generic methods, not GAT).

[nikomatsakis]

@eddyb it's not particularly dependent on GAT per se, but right now we don't have a notion of "where clauses that must be satisfied in order to project" -- I expect to be adding that as part of GAT, in which case it would apply here.

Note the sort of subtle distinction between:

trait Foo {
    type Bar: Baz;
}

This is a constraint on the impl that it supply a type that is Baz. Versus:

trait Foo {
    type Bar where Self: Sized;
}

This is a constraint on the one doing the projection that Self: Sized must hold for them to do it.

[eddyb]

@nikomatsakis We have them on methods and we check them when referring to those methods.
There is no real difference between "projecting a const" and "projecting an fn" here.