RFC: Generic const and static

[comex]

As it says on the tin.

Rendered

[arielb1]

I'm against generic statics because it is not obvious how they are monomorphized: currently, monomorphized items always have internal linkage, and monomorphizing them from 2 different crates creates 2 different copies. Doing this in a static could cause some confusion.

[comex]

I didn't think of that, but AFAIK C++ has always had that issue (it supports both static variables in generic functions and classes, and as of C++14, generic variables - plus I believe it guarantees uniqueness for pointers to specialized functions), and solves it by marking those symbols as weak, so the dynamic linker picks one for the whole program. Rust could do the same. Weak symbols have some performance impact, but as long as generic statics are uncommon it shouldn't matter. The number could be further whittled down by detecting truly immutable objects and going back to internal linkage for those - after all, if Rust doesn't guarantee uniqueness for fn instantiations, that line has already been crossed (i.e. surprising behavior with pointer comparisons), so there's little harm extending the same minor pitfall to immutable variables. (And of course, specializations involving non-exported types can also be internal.)

[aturon]

cc @eddyb @nikomatsakis

[eddyb]

IIRC we never considered associated statics because maintaining uniqueness was deemed unreasonably difficult/impossible (cc @alexcrichton) and plans for generic consts were supersceded by const fn.

[nikomatsakis]

We discussed this in the @rust-lang/lang meeting recently. I think that, at least for constants, we are all generally sympathetic to this goal, but we feel it's a bit premature to dive into it right now. The story with constants -- and especially constants and generics! -- is quite up in the air. We have const fns, associated constants, and the MIR transition, all of which affect how constants are implemented in the compiler and handled in the type system. Moreover, there is an obvious demand for constant-parameterized items (think fn foo<const N: usize>()). It seems most important to press on that last point, and MIR, and to some extent associated constants (which are entangled), and then return to this topic of generic constants.

(That said, I think one of the biggest points of tension here is between const fn and generic constants, since there seems to be quite some overlap between the two, though that is not to say we could not have both of them; perhaps they are both useful.)

[nikomatsakis]

Postponed under #1557