I don't see why this shouldn't be implemented. It certainly proves useful when working with generic allocators, without requiring a Copy bound on them. For example:
struct AllocWithInternalMutability {
...
}
impl<'a> Alloc for &'a AllocWithInternalMutability { ... }
impl AllocWithInternalMutability {
fn use_self(&self) {
//Ugly code
let mut ref_to_self=self;
use_alloc(&mut ref_to_self);
}
}
fn use_alloc<A: Alloc>(a: &mut A) {
//Multiple usages of `A` in here
a.alloc(...);
a.dealloc(...);
}
While having an impl<A: Alloc> Alloc for &mut A generic implementation would allow for this instead:
impl AllocWithInternalMutability {
fn use_self(&self) {
//Much cleaner
use_alloc(self);
}
}
fn use_alloc<A: Alloc>(mut a: A) {
//Multiple usages of `A` in here, thanks to `&mut A` also implementing `Alloc`
a.alloc(...);
a.dealloc(...);
}
The other current option is to require Copy on A, allowing for multiple uses of A without losing ownership.
I don't see why this shouldn't be implemented. It certainly proves useful when working with generic allocators, without requiring a
Copy
bound on them. For example:While having an
impl<A: Alloc> Alloc for &mut A
generic implementation would allow for this instead:The other current option is to require
Copy
onA
, allowing for multiple uses ofA
without losing ownership.