Tracking Issue for structs which needs an allocator

[TimDiekmann]

This WG wants to associate an allocator for all suitable structs. This issue tracks those structs, which are covered so far (non-exhaustive list):

• Box<T, A>: Support custom allocators in Box rust#77187
• Rc<T, A>: Add support for allocators in Rc & Arc rust#89132
• Arc<T, A>: Add support for allocators in Rc & Arc rust#89132
• String<A>: [WIP] Add support for custom allocator for String rust#101551
• CString<A>: Add support for custom allocator for (C)String rust#79500
• Vec<T, A>: Add support for custom allocators in Vec rust#78461
• VecDeque<T, A>: Add support for custom allocator in VecDeque rust#86595
• LinkedList<T, A>: Add support for allocators in LinkedList rust#103093
• HashMap<K, V, S, A>: Parametrize RawTable, HashSet and HashMap over an allocator hashbrown#133
• BTreeMap<K, V, A>: BTreeMap: Support custom allocators (v1.5) rust#98103
• HashSet<T, S, A>
• BTreeSet<T, A>: BTreeMap: Support custom allocators (v1.5) rust#98103
• BinaryHeap<T, A>: Make BinaryHeap parametric over Allocator rust#99339
• (OsString<A>)
• (PathBuf<A>)

[Ericson2314]

I've started in rust-lang/rust#60703 .

[ErichDonGubler]

@ObsidianMinor has asked about the Clone trait needing to also be modified:

(38183) Allocator aware std traits - rust-lang - Zulip

There's a number of traits that implicitly allocate to the global allocator like str ToOwned making a String<Global> and Clone String<Global> always making another String<Global> which would make it slightly more difficult to move data across allocators.

let  a: String<Global>  =  format!("hello world!");
let  b: String<System>  =  a.clone();  // nope, that's a String<Global>
let  b: String<System>  =  {  // we could do it manually
  let  mut  z: String<System>  =  String::new();
  z.push_str(a.as_str());
  z
};
let  b: String<System>  =  a.clone_in(System);  // or use a trait

let  s: &'static  str  =  "hello world!";
let  t: String<Global>  =  s.to_owned();
let  u: String<System>  =  s.to_owned();  // nope, it's Global again
let  v: String<System>  =  s.to\_owned\_in(System);

Is there an issue yet talking about traits like this?

Any reason this issue couldn't also accomodate Clone and any other traits/method we think of along the way? :)

[lachlansneff]

Thoughts on CloneIn: Clone trait instead of adding an additional clone_in method to `Clone?

[ErichDonGubler]

@lachlansneff: What would your motivation be for splitting into another trait?

[lachlansneff]

@ErichDonGubler

Adding it to Clone would be a breaking change. I can't think of a valid default implementation for Clone::clone_in and many types would have nothing to do with an allocator.

[TimDiekmann]

I think this should be added to the list in #15.
When implementing Box and RawVec I had to limit those traits to allocators, which implements Default which is rather limiting.

[TimDiekmann]

However, as @SimonSapin noticed in #15 (comment), it's probably fine to add them at a later point.
Additionally, if you really need those traits, I think a third party trait should be possible here until landed.

[ErichDonGubler]

Okay. I'm guessing it'd look something like this?

pub trait CloneIn {
    type Alloc: Alloc;

    fn clone_in(&self, allocator: Self::Alloc) -> T;
}

[Amanieu]

Adding it to Clone would be a breaking change. I can't think of a valid default implementation for Clone::clone_in and many types would have nothing to do with an allocator.

Wouldn't just calling regular clone and ignoring the allocator be a valid default implementation?

[lachlansneff]

@Amanieu, how could it produce a SomeType<A> when Clone::clone would just create a SomeType<System>?