Repository navigation
[SUGGESTION] Add support for static variables #212
Description
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.
Activity
hsutter commentedon Jan 8, 2023
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
constexpror optionallyconstinit 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 ofcall_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 commentedon Jan 8, 2023
Sorry if this is a noob question, but why would
constinitwithoutconstnot be okay? My understanding is thatconstinitcalls aconstexprconstructor 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 amutablemember, would that matter here?hsutter commentedon Jan 9, 2023
@Cons-Cat Good question! Real quick answer: Because of concurrency safety and 'const by default.'
switch-blade-stuff commentedon Jan 9, 2023
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 commentedon Jan 9, 2023
I agree that (mutable)
statics can be a great pain in the back. I have seen apps crashing after returning frommain()because of issues with destruction ofstatics.A mechanism that replaces them with something easier to control and reason about would be a big +.
switch-blade-stuff commentedon Jan 9, 2023
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.