I think the answer is that this isn't possible, but I'd love to be able to create a static that is generic, e.g. within a function or a trait. Since the compiler monomorphizes the function anyways, is there any reason why we couldn't write a function like:
Unlike with functions, duplicating generics can be behavior changing in case of interior mutability. It is impossible to prevent generic items being duplicated in the general case. If two crates use the same generic instantiation, they would either have to codegen it separately (as rustc currently does) or have some way of delaying codegen until link time (which is only really possible with LTO, and even then doesn't fix dynamic libraries).
But dynamic libraries can't contain generics, can they? For pretty much the same reason why dyn Trait methods can't be generic – there would be no way to codegen yet-unknown instantiations. So dylibs don't need to be fixed.
Note that C++ for example does support generic statics with the expected semantics, so it appears to be at least technically possible. Whether there are any other gotchas I don't know off the top of my head.
But how do you use it? Surely then libstd needs to be linked against by rustc in order to instantiate said generics, so the dylib is not the final product of the compilation process. This means that there is still room for compile-time/link-time arbitration after the creation of the dylib.
I'm confused. Are you saying that you can dlopen libstd.dylib, then somehow usefully access a generic inside by instantiating it with concrete types, purely at dynamic-link-time, without having to rely on rustc? And if not, then why is it a problem that uninstantiable generics exist in the library?
You can't access generics directly using dlopen. However imgine you have a dylib exposing a generic. Then two different dylibs call the generic with the same substitutions from #[no_mangle] functions. If you then dlopen these two dylibs there is absolutely no way to prevent duplicating the generic function with identical substitutions.
Regarding the problem at hand, yeah, a map from TypeIds to Box<dyn Any + Send + Sync> is the usual workaround, either written as simply as that when performance doesn't matter, or fine-tuning it like you have.
There is another approach, for the case that ought to be doable at compile-time, which is when you know, beforehand, the set of types that may be involved, and if you really need unicity of the shared static:
the latter point is referring to the fact that in Rust you can have a static S: T or you can have a const AT_S: &'static T; with the latter actually being easy to feature generically, but with the caveat that different AT_S instantiations may lead to duplicated static storage; so this is only useful when the statics are playing a semantically meaningless / only-for-performance operation, such as memoization ↩︎