Closed
Description
This is a tracking issue for the unstable static_mutex
, static_condvar
, and static_rwlock
features in the standard library. Each of these represents a separate StaticFoo
type (next to the type Foo
) to provide a synchronization primitive that can be constructed in a static context. This unfortunately has a few drawbacks:
StaticMutex
does not have a type parameter for the data that it protects (unlikeMutex<T>
)- Having two types for almost the same purpose is quite unfortunate.
Ideally all of these types would be removed in favor of being able to construct a Mutex<T>
statically. This can almost be done with const fn
, but the implementation of each of these primitives currently has an internal Box
which can't be constructed in a static context. A solution should probably be devised along the lines of:
- A "stable address" primitive could be created which is a
Box
at runtime and just a plain address when inlined into a static. It also wouldn't have a destructor for the purposes of checking whether statics have destructors. - The
box
operator could be allowed in aconst fn
context perhaps. Instead of allocating memory on the heap it could instead "allocate" memory in the data section of an executable at compile time. The destructor would end up being ignored and never run somehow, possibly.