Make LazyCell<T, F> and LazyLock<T, F> covariant in both T and F

[WaffleLapkin]

See explanation for why it's valid that I wrote as a comment in LazyCell:

rust/library/core/src/cell/lazy.rs

Lines 55 to 91 in 5da2332

	// It is non-obvious why `LazyCell` can be covariant in both `T` and `F`
	// (and thus use `CovariantUnsafeCell`)...
	//
	// # `F`
	//
	// `F` is the easier to explain one; The state only ever transitions *out* of `Uninit(F)`
	// (to either `Poisoned` or `Init(T)`), and never into it. In other words `F` is only ever
	// read, not written.
	//
	// One could imagine `LazyCell` implemented as
	// ```
	// struct {
	// state: UnsafeCell<Uninit | Init(T) | Poisoned>,
	// f: ManuallyDrop<F>,
	// }
	// ```
	// which would make it "obviously" covariant in `F`.
	//
	// **NOTE**: the important invariant here is that we never allow writing `F` through
	// `&LazyCell`.
	//
	// # `T`
	//
	// Why `LazyCell` can be covariant in `T` is even more subtle. We do allow writing `T` through
	// a `&LazyCell`, which would normally force us to make `LazyCell` invariant in `T`. However,
	// the only value that we allow writing is one returned by `F`... and we don't allow changing
	// `F`. So even if a user gets a `&LazyCell<LessrestrictedVersionOfT>`, they cannot write the
	// `LessrestrictedVersionOfT` through it.
	//
	// **NOTE**: the important invariants here are that
	// 1. `T` can only be written through `&LazyCell<T, F>` by being returned from `F`
	// 2. `F` cannot be overwritten after `LazyCell` creation
	//
	// # Conclusion
	//
	// `LazyCell` can be covariant in both `T` and `F`... provided the non-local invariants which
	// are listed above.

r? libs-api

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ChayimFriedman2]

This two assumptions are both fragile. We might want to provide an API in the future to clear a LazyCell similar to OnceCell, and we might want to provide an API to set the value directly without the callback. Making this type covariant in T will prohibit both.

I think the safe thing to do is to make it covariant in F but leave it invariant in T.

View changes since the review

[WaffleLapkin]

What do you mean by "API [...] to clear a LazyCell similar to OnceCell"?

If you are talking about take, then it would not be a problem for these assumptions¹. For LazyCell you would need something like fn take(&mut self, new_initializer: F) -> Result<T, F>. Notably since it would have to take &mut self, it does not interact with variance².

Setting the value without callback would require LazyCell to be invariant in T. If we want to add such an API we should keep T invariant.

Footnotes

1. Maybe they are not very clearly stated... I wish we had a better language to talk about variance... ↩

2. &mut T is invariant in T and prohibits other references to the value, so you can't shorten the lifetime and give and unexpectedly dead reference to any observer. ↩

[ChayimFriedman2]

Alright, maybe take() isn't a problem, but fn set(&self, value: T) -> Result<(), T> is.