The interaction with
no_std is definitely something that would need to be figured out!
If this is implemented using the same infrastructure as C++ static initializers, then the infrastructure they would run on wouldn’t depend on allocation or anything else in
std. It could even still run without the rust initialization in
I guess if we’re implementing it as part of the rust start code, then there’s more to figure out here. Thanks for bringing it up!
With the multiple functions, this is necessary in order to allow things like
inventory to function. If we were only allowed one function per crate, there wouldn’t be a reasonable way for an attribute-based macro to register multiple things on independent items to run on startup. As this kind of “registration” is one of the main use cases, I would be inclined to say that having multiple functions is needed.
I just mean this as far as it is true in rust in general. The following isn’t valid rust, and has never been valid:
static X: &str;
Global constructors wouldn’t allow you to write this either - all statics would need to be initialized to something, still. Even
std::mem::uninitialized() is non-const, so I don’t think it’s possible at all to do this?
MaybeUninit, but even then, it’s not really “uninitialized” since unsafe code is required to read it later. This is a concern, but I don’t think it’s a large one.
To be clear, I’m proposing not changing these rules. Global constructors would not introduce the ability to have uninitialized statics, nor take it away (since we don’t currently have it).
With all that said, I think going forward with a
linkme-based method is probably more sane. I’ve not put together a proposal, but I’ll probably be trying to do that later next month or sometime soon.