[SUGGESTION] Add support for static variables

[jarzec]

The title says it all, really - support for static variables is a simple Cpp1 feature that is not yet implemented in Cpp2.
I think that in order to preserve the beauty of the "left-to-rightness" the static qualifier should only be allowed as the left-most one, eps. that this qualifies the variable rather than its type.

[hsutter]

There are global (namespace-scope) statics, class statics, and function-local statics.

For all three, there are potential concurrency issues, but sometimes you really do need a shared state so that part doesn't worry me unduly.

For the first two, though, it's important to avoid the "static initialization order fiasco" -- if they are allowed at all, they must not allow dynamic initialization. My current thinking is to either (a) allow them but make them always constexpr or optionally constinit const, or (b) don't allow them and tell programmers to instead wrap them in a function instead.

For the third, I would either (a) support them, or (b) provide a std::singleton<name, type> type that does the work and is implemented in terms of call_once -- i.e., make it a library feature.

I've been resisting making any choices here yet because I feel good about dragging my feet on adding global shared state support until we see if it's really a must-have language feature (you can get the same effect with a library and I'd like to see the use cases that don't do well with a library), and also because I want to get a feel for classes first which are the next major feature to implement.

[Cons-Cat]

constinit const

Sorry if this is a noob question, but why would constinit without const not be okay? My understanding is that constinit calls a constexpr constructor so that there is no initialization at runtime. But modifying it afterwards shouldn't cause problems related to SIOF as far as I know, but I assume I'm missing something? And what if it has a mutable member, would that matter here?

[hsutter]

@Cons-Cat Good question! Real quick answer: Because of concurrency safety and 'const by default.'

[switch-blade-stuff]

For the third, I would either (a) support them, or (b) provide a std::singleton<name, type> type that does the work and is implemented in terms of call_once -- i.e., make it a library feature.

To my knowledge, that is already what happens with function-local statics. At least on GCC/CLang there is an atomic sentinel flag that is used in conjunction with futex'es (or a mutex buffer if futex is unavailable) that is checked for dynamic initialization of local statics. Can't speak for MSVC though.

As for namespace- and type-scope statics, I think it would be better to put it behind a safety toggle, since you sometimes do need a mutable global that you would initialize and/or mutate manually. Now, you probably wouldn't expose that to a public API, but internally it might still be useful.

[jarzec]

I agree that (mutable) statics can be a great pain in the back. I have seen apps crashing after returning from main() because of issues with destruction of statics.
A mechanism that replaces them with something easier to control and reason about would be a big +.

[switch-blade-stuff]

Also ought to mention, @hsutter is there any plan to address destruction of static objects? Static object destructors may never be called on certain platforms like musl libc, especially when using dynamic library loading like with dlopen/dlclose.

Although I do not see a good way to handle this outside of managing a custom runtime.