search

rust-lang / wg-allocators

Home of the Allocators working group: Paving a path for a standard set of allocator traits to be used in collections!
http://bit.ly/hello-wg-allocators
205 stars 9 forks source link

Make safety constraints for `grow` and `shrink` more strict #70

Closed TimDiekmann closed 3 years ago

TimDiekmann commented 3 years ago

Currently, it requires, that the new size must be greater/smaller or equal to the current size. This is because the trait also supports ZSTs, as growing an array of ZSTs will still result in a size of zero. I propose to restrict this clause to

new_size must be strictly greater(smaller) than layout.size() or both must be zero

Let's discuss/vote which constraint makes more sense.

TimDiekmann commented 3 years ago

Personally I don't have a strong opinion on this.

Amanieu commented 3 years ago

I think that we should continue allowing this for consistency with our stance on ZSTs.

With that said, the equal case should be considered niche so there is no requirement for the allocator to handle it efficiently. This means that the allocator should not specifically check for new_size == layout.size() but instead just blindly allocate a new block and copy the contents of the old block into it.

TimDiekmann commented 3 years ago

I think that we should continue allowing this for consistency with our stance on ZSTs.

Probably this.

With that said, the equal case should be considered niche so there is no requirement for the allocator to handle it efficiently. This means that the allocator should not specifically check for new_size == layout.size() but instead just blindly allocate a new block and copy the contents of the old block into it.

We really should remove the check and do a perf-run. This should improve performance at least a little bit, as less code has to be optimized out.