Talking about the RFC:
I'll mention that the motivation in here is partially covered by associated constants today:
The most important benefit is the ability to generate a separate static allocation in the binary for each used set of type parameters. The use case for scalar-typed generic
consts somewhat overlaps with
const fns, but when a static address is needed, Rust currently provides no alternative or workaround. (In particular,
statics inside generic
fns cannot refer to the outer
fn's type parameters, nor can associated
consts inside traits refer to trait generic parameters or to
Self. Actually, you can technically do it with
since associated constants can now refer to the generic parameters of the
impl block or
Self), and can construct static references (so long as the type doesn't contain internal mutability) .
Also, the example that constructs
HashKeyData can be written using associated constants:
V associated constant is a
&'static HashKeyData to have the same effect as referencing a generic static, except that it doesn't guarantee a single address for all instances of
As I understand it,
HKD::<Bar>::V accross compilation units can produce different addresses.
Generic constants would have the advantage that they'd be nicer to use than associated constants for this purpose.
Generic statics would have the advantages that they guarantee all instances of
HKD is a generic static) have the same address, and would allow taking static references to an internally mutable type.