I am interested about your opinion about an prev_init_panicked method (not attached to the name).
If we don't want to give guarantees about side effects, it is not possible to implement poisoning with user code. Even sync::Lazy relies on side effects to synchronize its Cell<Option<F>>.
I still think it is the right choice to have OnceCell act as if there is no poisoning in the common case is a good default, as it matches what you care about: initialization, not upholding some variant as running exactly once.
For std the changes to the implementation are minimal.
For the parking_lot implementation I had to go with the same pattern to use a finalizer that sets the appropriate state on panic/err/success. To keep the size of OnceCell the same as before, I used an AtomicU8 which bumps the MSRV for the parking_lot feature to 1.34.
:scream: don't have time to look into this, but, in general, I would prefer to just defer the poisoning decision to t-libs, as I have zero intuition where it is useful and where it is not
I am interested about your opinion about an
prev_init_panicked
method (not attached to the name).If we don't want to give guarantees about side effects, it is not possible to implement poisoning with user code. Even
sync::Lazy
relies on side effects to synchronize itsCell<Option<F>>
.I still think it is the right choice to have
OnceCell
act as if there is no poisoning in the common case is a good default, as it matches what you care about: initialization, not upholding some variant as running exactly once.For
std
the changes to the implementation are minimal.For the
parking_lot
implementation I had to go with the same pattern to use a finalizer that sets the appropriate state on panic/err/success. To keep the size ofOnceCell
the same as before, I used anAtomicU8
which bumps the MSRV for theparking_lot
feature to 1.34.