Pre-RFC: Associated statics

[Centril]

Thanks for taking the time to write this! Here are some questions & notes I have to aid in making progress...

@mjbshaw

Motivation

This section feels thin; before filing it against rust-lang/rfcs I'd encourage you to collect more motivation, especially real world use cases.

@mjbshaw

Generic structs and traits cannot contain associated statics

I'd like to see some discussion on why given this restriction it's OK to have associated trait statics at all given that the first implicit parameter of a trait makes for an implicitly generic static you may end up in:

// crate A:
// ------------------------
pub trait Foo { static Bar: usize }

pub struct Alpha;
pub struct Beta;

impl Foo for Alpha { static Bar: usize = 42; }
impl Foo for Beta { static Bar: usize = 24; }

// crate B
// ------------------------
pub fn takes_foo<T: Foo>() { ... }

In particular, some reasoning around how we can guarantee that no matter where <X as Foo>::Bar is being projected, it always end up to the same memory address (which is something unsafe { ... } should be able to assume).

@mjbshaw

Reference-level explanation

You've discussed the static semantics of your proposed changes, but not the dynamic/operational semantics. So even if it might be obvious, I'd like a discussion in this section of the proposal on the dynamic semantics of all the bits and pieces. You don't have to specify it formally, but it should be clear what is meant.

I'd also move out any rationale for assorted choices in the reference to the section on... well.. the rationale..

@mjbshaw

Even if the static does not use the generic type parameter, it is unclear whether all monomorphizations should share a single static or if they should each get their own. For example:

struct Struct<T>(std::marker::PhantomData<T>);
impl<T> Struct<T> {
    static STATIC: usize = 42;
}

It is unclear whether Struct<u8>::Static should be the same static as Sruct<i8>::Static , or if they should refer to unique statics (in which case this hits the same problem on Windows as above). This can be addressed in a later RFC if desired.

In all discussions hitherto about generic statics it was always clear that each monomorphization would get its own memory location... why else would you have a generic static? And furthermore, given associated types you may run into:

trait Foo {
    type Bar;
    static Baz: Self::Bar;
}

struct Gamma;
struct Delta;

impl Foo for Gamma {
    type Bar = u8;
    static Foo = 42;
}

impl Foo for Delta {
    type Bar = bool;
    static Foo = false;
}

Since if you'd have u8 and bool at the same memory location, type preservation is directly violated, and you'd get unsoundness.

Speaking of associated types; I think you'll need to consider impl specialization + associated types and whether when generics are used it's reasonable to expect that <X as Foo>::Bar always refers to the same memory address.

@mjbshaw

Prior art

Some discussion on statics in C++ might be useful here.

@mjbshaw

I’m intentionally trying to keep this RFC proposal as simple as possible and avoid bikeshed-inducing proposals. Currently, associated statics aren’t permitted at all, even in the simplest case. I’m trying to fix that in this RFC to do two things:

1. Unblock users who only need the simplest case of associated statics.
2. Open the door to exploration for more difficult cases (like generic statics). I believe it will be easier to explore these different cases once simple associated statics are supported.

Additionally, I’m hoping that by keeping the RFC simple we can get something implemented (and hopefully stabilized) sooner than if we started with the whole kitchen sink. I think the incremental approach here is the ideal approach.

With that in mind, I’m not going to discuss generic statics further in an attempt to keep this discussion focused. I appreciate the points you’ve raised, Soni, and I hope we can discuss and explore them further in a future discussion or RFC.

That's fair and I would be OK with experimenting with associated statics on nightly. However, I wouldn't be inclined to stabilize associated statics without first having at the very least an accepted design + implementation on nightly for associated statics in generic implementations. I have this constraint to ensure that when we're done with associated statics, what comes out is coherent and not a patchwork of inconsistencies.

I think the main hurdle for generic statics are dylibs (cc @hanna-kruppe, How about "generic global variables"? - #8 by hanna-kruppe, Generic-type-dependent static data - #7 by hanna-kruppe, Generic-type-dependent static data - #7 by hanna-kruppe, Discord). We might want to kill them off entirely; but we should consider whether we are OK with preventing future better dynamic linking models (might also interact with hotloading a la erlang?).