Repository navigation
Permit trait object types where all (non-generic) associated constants are specified (via assoc item bindings) #130300
Description
Important context: Inherently, this would only become legal under the ongoing lang experiment
associated_const_equality(#92827).
We permit trait object types where all 'active'1 non-generic associated types are specified (via assoc item bindings). We should extend this to cover 'active' non-generic2 associated constants, too.
Note that I haven't spent much time thinking about soundness yet. I still need to iron out the exact rules. Implementation-wise, I'm almost certain that any advances are blocked by #120905 (more precisely, its underlying issue) which I presume we would need to fix first for correctness.
Minimal & contrived example of something that would start compiling:
#![feature(associated_const_equality)]
trait Trait {
const K: ();
}
fn main() {
let _: dyn Trait<K = { () }>;
}Presently, this gets rejected and we emit E0038 (cannot be made into an object).
Lastly, lest I forget, we should emit the lint unused_associated_type_bounds3 (#112319) for assoc const bindings where the corresp. assoc const is 'disabled' via where Self: Sized which is only possible to write under generic_const_items (#113521).
Footnotes
-
I.e., not 'made inactive' / 'disabled' via
where Self: Sized(Don't require associated types with Self: Sized bounds indyn Traitobjects #112319). ↩ -
This might or might not be a temporary restriction. For context, we don't (yet) permit GAT bindings in trait object types either on stable, due to soundness concerns. See
generic_associated_types_extended(Tracking Issue for extended generic associated types #95451). Also note that generic assoc consts (GACs) are only available undergeneric_const_items(Tracking issue for generic const items #113521). ↩ -
Indeed, the name would no longer be accurate. Ideally, we would rename the lint when generalizing it. ↩
Activity
fmease commentedon Jan 29, 2025
After poking around some more, I've come to the same conclusion that this is blocked on extending the normalization rules of
UnevaluatedConst(const projections) (see also #120905).Like,
rustc_trait_selection::traits::try_evaluate_constwhich is the entry point we're interested in I think doesn't do much except deferring "overly generic" const projects (where are those ultimately solved though? I couldn't find that out (try_evaluated_constagain?)) or delegating normalization to the const evaluation machinery.I presume what we would want to assemble some other candidates in
try_evaluate_const(?) like we do for type projections. Most importantly ParamEnv candidates (cf.rustc_trait_selection::traits::project::assemble_candidates_from_param_env) and perform some sort of selection. Nothing feels like the right place though but that's likely because I don't know enough yet. Esp. due to the const projection deferral. I don't want to touch anything rn because this is GCE→(m)GCA territory and maybe also next-solver territory (in the sense that we likely want to implement that in the next solver only because doing so in the old solver (too) would be wasted effort and overly complex and fragile).This all seems relevant to "ACE in dyn" because lifting the dyn compatibility restrictions around assoc consts just lead to another dyn incompatibility: Given
trait Tr { const N: usize; fn check(&self, _: [(); Self::N]); }, the trait refTr<N = 1>remains dyn incompatible because presumably[(); Self::N]doesn't normalize to[(); 1]leading to an illegalSelfty param remaining.fmease commentedon Aug 26, 2025
As I've just noted over at #120905, under mGCA (min_generic_const_args) most (or at least more) of the aforementioned cases should work compared to GCE. So I'll hopefully pick this up again soon and try to impl it gated not only under ACE but also under mGCA.
Maybe it's too soon however. After all, once mGCA is more complete, ACEs will be restricted to mGCA as discussed with Boxy. I dunno, whatever.
BoxyUwU commentedon Jan 2, 2026
I expect this is unblocked now and can be implemented. Normalization of associated consts under
mGCAin theory should "just work"Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU
Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU
Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU
Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU
Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU
Auto merge of #150843 - fmease:dyn-ace, r=BoxyUwU