bluurryy
bluurryy
PR #357 fixes this.
This doesn't work because `Box` implements `CoerceUnsized` (a nightly trait) which bumpalo's `Box` doesn't. I've seen the allocator_api2's [`unsize_box`](https://docs.rs/allocator-api2/latest/allocator_api2/macro.unsize_box.html) macro which allows such a coercion in stable rust. Afaik the...
Yes using this macro is safe. This will only allow a conversion to a type which it can safely coerce to. Essentially the same thing is happening as with the...
Using the nightly feature `unsize`, using the `Unsize` trait, you could write such a method (and that method would be safe). But when you're already using nightly features you might...
> To prevent users from unwittingly allocating structs that they aren't aware need to have their `Drop` methods run, the `alloc*` and `try_alloc*` methods should add the type constraint `T:...
It would work with a static assertion. But it would be implemented like so: ```rust struct AssertNoDrop(PhantomData); impl AssertNoDrop { const ASSERT_NO_DROP: () = assert!(!core::mem::needs_drop::(), "T must not need drop");...
> So I really don't get the motivation for this issue. I don't think its a bad idea to be more explicit that you're leaking memory *if* there is way...
> It is _sometimes_ possible to achieve this output today by manually writing `` and ``: > > `/// x.checked_add(y).unwrap_unchecked()` > > But the reason I say "sometimes" and the...
I don't think this would be a breaking change. How is it breaking? EDIT: since there is a blanket impl `Allocator` for all `&T` where `T: Allocator`
> Could you explain how this is different than https://github.com/crate-ci/cargo-release/issues/701 that a separate issue is opened? I was thinking this is a different issue that might have the same root...