Closed 95th closed 4 years ago
I don't think that's the case, since the type of the allocator is encoded in the type of the allocated object. This way any lifetime inside the allocator will also be part of the allocated type.
From what I understand (and @TimDiekmann can correct me here), the {A,Dea,Rea}llocRef
traits are intended to be implemented on "handles" of some sort, be it a smart pointer structure or a direct reference -- the -Ref
suffix is supposed to encode that bit of knowledge. So, as @JelteF says, any lifetimes associated with a handle to an allocator should be encoded by what you implement those traits for.
I think that your confusion is something that shouldn't be ignored, though. I'm planning on doing a documentation push this weekend to make it so that the answer to your question can at least be learned without filing an issue. As a user, how do you think that we can help other allocator users to understand this?
Ah I see.that make sense. Thanks for the explanation. I think if we had an example code using this approach, that would make it easier to understand.
I was looking into https://github.com/TimDiekmann/alloc-wg repo and came across
pub fn new_in(mut a: B::Ref) -> Self
.I find it confusing because we are passing in a custom allocator which may not have static lifetime and the resulting object is an owned value. Won't this be able to outlive the allocator? Shouldn't the function return
&mut Self
?