# Stabilizing the Allocator API

Docs say nothing about pinning: If you allocate and then drop the allocator without calling deallocate, can the allocator free the underlying memory?

Amanieu: The answer is yes

So you can't allocate pinned objects, unless the allocator is `'static`. If it's `'static` we require (somewhere) that the memory must retain its validity.

Taylor: No, docs say that you can drop the allocation when the allocator is dropped...

Amanieu: the allocator itself must be static, but the lifetime to the allocator does not have to be

> Memory blocks that are currently allocated by an allocator, must point to valid memory, and retain their validity while until either:
> - the memory block is deallocated, or
> - the allocator is dropped.

struct Alloc {} // ?
let something = ..;
let alloc = ..;
let boxed = Box::new_in(something, alloc);
let pinboxed: Pin<Box<T, Alloc>> = Box::into_pin(boxed);
// ?
Box::leak(pinboxed)

Amanieu: **it's a bug that `Box::leak` does not leak the allocator. That's unsound.**

- (Later follow-up, it's not actually unsound, just that the code isn't very explicit. Fixed by https://github.com/rust-lang/rust/pull/141219)

Taylor: [`Box::into_pin`](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.into_pin), what happens if you leak that?

the8472: this is ok because the destructor is never called, and so the allocator never deallocates.

Taylor: I'd like stack-based allocators to be able to hold pinned objects.

the8472: RFC to allow overlapping marker trait implementations is already implemented? Would allow a marker trait rather than the static bound.

Allocator::grow is very poorly specified
- when can you return an error? alignment problems only or also out-of-memory problems?
- people will treat any error as OOM, probably

What is the API benefit of having separate grow/shrink methods?
- Amanieu: Usually entirely different codepaths in allocators.

async hardware allocations???

Grow improvements:
- Don't allow? changing ~~layout~~ parts of layout like alignment, only size
- Take initializated size as arg
- grow_in_place requires StorageResized -- check with Ralf
- [Should we allow StorageLive on a live local](https://github.com/rust-lang/rust/issues/99160)

## Dealloc trait

https://github.com/rust-lang/wg-allocators/issues/112

## Grow and alignment-changing

- there's benefits to being able to do it like taking `Vec<T>`'s allocation and reusing it for a `Vec<U>`
- but also it's a horrid pain to actually do in practice so lots of allocators want to be able to opt out

## cross-allocator cloning

- we impl FromIterator only for GlobalAlloc?
- because of inference issues.
- defaults affect inference! defaults affect inference! defaults affect inference!

## string allocator param???

- associated constants???
- cannot create a path to assoc constants because you need to specify the generics???

## Allocations optimized away

- Only for `Global`
- Do we want it to apply to other allocators?
- Some allocator implementers don't want it to!
- Provenance???!?
- hypothetical intrinsic that mints a new provenance???
- does provenance even make sense inside an allocator?
- What does LLVM need to detect this? Sounds like it is currently a very specific signature that probably doesn't match what we have.

## Support zero-sized allocation

Better let the caller handle it. Make it UB so allocator doesn't need to.

- If the allocator must allow ZSTs, then it's allocator-dependent whether things "just work" or if it needs some kind of check
- Amanieu: simplicity for the caller is a reason we would want the allocator to handle the check/behavior
- `NonZeroLayout` would be nice
- Easier to optimize out ZST checks on the caller side

tg: this issue is worth a read, it has some more concrete proposals that seem to approximately mirror the consensus in the meeting https://github.com/rust-lang/rust/issues/32838#issuecomment-2760323045