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
203 stars 9 forks source link

Should most allocators be Clone? #88

Closed shlevy closed 2 years ago

shlevy commented 3 years ago

I'm creating a data structure that includes Boxes and Vecs and Vecs of Boxes, and I find myself between two choices:

  1. Have the top-level data structure own the Allocator and have each nested structure use the free &A implementation
  2. Require the Allocator to be Clone and just clone it at each usage point

Based on this section in the docs:

cloning or moving the allocator must not invalidate memory blocks returned from this allocator. A cloned allocator must behave like the same allocator

it seems like the expected pattern is 2, and that therefore most allocators will be Clone. Is that correct?

Amanieu commented 3 years ago

hashbrown also requires allocators to be Clone. In practice I would expect the vast majority of allocators to be Clone.

RustyYato commented 3 years ago

Note that you can always create a Clone allocator by using &T. So the Clone bound is strictly more general, as it also allows non-&T allocators.

cmazakas commented 2 years ago

In general, yes.

Allocators should generally be a cheap-to-copy handle to an upstream memory resource.

shlevy commented 2 years ago

Seems like there's consensus, thanks!