Daniel Henry-Mantilla

Regarding the fix, I think it should feature `// Safety` comments as well in the `unsafe { … }` block, about `main` not being called from other threads (since not...

Good idea!

This is a known hard problem for proc-macros. I've been recently re-thinking about this, and here is the least-bad solution I can think of: 1. Make `::bytemuck` export a hidden-ish...

Take this code pattern (which I expect to be kind of reimplemented by crate users for similar but not quite equal needs): https://docs.rs/uninit/0.1.0/src/uninit/lib.rs.html#195-226 The last step, where it is assumed...

Thanks for reminding me of this PR; I now have enough time to go back at tackling and polishing this 🙂 . For instance, the `uninit` crate has been updated...

@bjorn3 wouldn't that break higher-order signatures (which are implemented as overloads over the input lifetimes)? FWIW, this question is related to that of the `Resume` parameter for `Generator`s. a silly...

Note that there was some more discussion about this [over Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Desired.20behavior.20of.20.60write!.60.20is.20unimplementable). My personal _short-term_ solution, here, _barring two-phased borrows_, would be to have a helper extension method to take care...

@eddyb yeah, totally[^robustness], sorry for the redundant suggestion 🙇, I somehow scrolled past your post. - so, would the suggested workaround tackle the remainging two-phased borrows failures? EDIT: I've decided...

Could you provide, in the PR description, a summary of the new resulting API, without the implementation details? That would be quite useful to skim through the changes 🙏 Here...

Sorry for the delay in my answer, @nrc, and thank you for taking my input into consideration 🙏 lifetime names (and position) > buffer is such an overloaded term Ah...