GlobalAlloc::realloc’s parameters are backward

[SimonSapin]

The GlobalAlloc trait is stable with this method:

unsafe fn realloc(&self, ptr: *mut u8, layout: Layout, new_size: usize) -> *mut u8

(And similarly the std::alloc::realloc function.)

Note new_size: usize instead of new_layout: Layout. This is because this method does not support changing the alignment.

When (re)allocation fails (when the method returns null), the caller typically wants to call handle_alloc_error which takes a Layout. This value needs to be created with code like Layout::from_size_align(new_size, layout.align()).unwrap(). It would be better if the value passed to the error handler was already available. This would be the case if the parameters to realloc were old_size: usize, new_layout: Layout instead.

For the Alloc trait, we could:

• Keep consistency with GlobalAlloc, or
• Change to old_size: usize, new_layout: Layout, or
• If we also decide to lift the same-alignment restriction (which should be discussed in Support reallocating to a different alignment? #5), then the signature becomes old_layout: Layout, new_layout: Layout and this issue is moot.

[TimDiekmann]

If we also decide to lift the same-alignment restriction (which should be discussed separately, feel free to file a dedicated issue), then the signature becomes old_layout: Layout, new_layout: Layout and this issue is moot.

I like this option the most, as this may be valid for arbitrary allocators.

[SimonSapin]

Alright, I’ve filed #5 for that discussion.

[SimonSapin]

#5 is closed, and AllocRef’s grow and shrink methods still take layout: Layout, new_size: usize. Should they be changed to old_size: usize, new_layout: Layout?

[TimDiekmann]

I find it confusing when the new_ parameter gets an alignment, but that has to match the alignment of the old layout. Surely it is more convenient when one already has the layout passed to the method, but that Layout also has to be constructed beforehand.

[TimDiekmann]

As the AllocRef trait changed a lot since this issue was opend, I opened #69 and closing this in favor of the linked issue.