Make `unsync::Lazy<T, F>` covariant in `F`

[danielhenrymantilla]

"Continuation" from https://github.com/matklad/once_cell/pull/230, which partially handles https://github.com/matklad/once_cell/issues/167.

• Incidentally, this also makes unsync::Lazy smaller in size in most cases, since T and F are now sharing the same union storage.

The sync can basically use the same logic (my PR paves the way for such a follow-up PR), only the whole thing would need to be moved to each of the possible implementations of sync::OnceCell, and special care to synchronization semantics will be in order, which I prefer to let somebody else do.

[matklad]

bors r+

Thanks!

[bors[bot]]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here. For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• Rust

[matklad]

Ah, I think this doesn't actually work as we want it too :sob:

I think we've lost dropchk here, no?

Before, we didn't have a custom drop, so a Lazy<&'a T> allowed dangling 'a at the point where the Lazy is dropped.

In this variation, we now have a custom drop, so that won't be allowed. There's a dropchk test for OnceCell, but not for lazy.

Is there some way to have #[may_dangle] on stable?

[matklad]

https://github.com/rust-lang/rust/issues/34761#issuecomment-1256691491

[danielhenrymantilla]

Oh, good thing this wasn't released!

• Note: let's try to add arrrr tests for Lazy too then 😅

Is there some way to have #[may_dangle] on stable?

Short answer is no; slightly longer answer is the post you've linked to, but which generalizes with great difficulty (it's very situation-specific)

Even longer answer, which I was planning to write a crate and blog post about it, is that with HKTs/GATs it is possible to define an advanced API that would let people opt-into their specific usage #[may_dangle] at the cost of having to use that type.

So for once_cell this is a big no, since it would be a major usability regression, in comparison of which lack-of-covariance over F pales.

• But for those curious, the API would be something like LazyMayDangle<'a, Gat!(&'_ T)>, with Lazy<T> then being some kind of alias for LazyMayDangle<'static, Gat!(T)>.

Conclusion (to share back to #167): blocked due to lack of #[may_dangle]: only stdlib itself may realistically feature this on stable Rust, but stdlib is precisely the area where things ought to remain somewhat KISS 😅

I'm submitting a revert as we speak (my latest PR on the topic), and I apologize for the inconvenience, @matklad; I reckon it must have been quite a spam of notifications on your end, for a niche thing, and which hasn't panned out