-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify Arc
and Rc
so the allocator is moved into the inner allocation
#3540
Comments
This would be problematic for This would also require There's also something to be said for consistency; This would also mean that |
Of course, these changes would also be applied to
Yeah, a slightly inconvenient of this issue is that it's a breaking change. Although Rust has editions, so maybe the change could be between editions. I'm not sure if editions also include type changes or just compiler features...
I don't know if that is a convincing argument against this. After all Also, maybe they should, though as you said, their guarantees make it much more difficult. Probably not worth it for those types.
Not sure if I understand that sentence, but I don't see a problem on it. If you use different allocators, you would always have to use generics, how does this feature impact on that specific issue? |
I don't see how it would be a breaking change, actually. All of the
It is a fairly common pattern to do something similar the following to deallocate a heap-allocated container without dropping the allocator itself: // let boxed: Box<T, A> = ...;
let (ptr, alloc) = Box::into_raw_with_allocator(boxed);
let boxed: Box<T, &A> = unsafe { Box::from_raw_in(ptr, &alloc) };
drop(boxed); // Deallocate using `impl<A: Allocator> Allocator for &A`
// use alloc for other things This pattern is used in If Footnotes
|
Great.
I see. But couldn't the pattern be replaced with a new one? For example,
Oh, well, I can't ague with opinions. So I don't know that to say about this, even if it's a hint, it's not a demand. |
Basically, at the moment
Arc<T, A>
and itsWeak<T, A>
uses:(Something similar happens in
Rc
and itsWeak
, so this whole issue could also be applied to them.)My idea is to move
alloc
fromArc
andWeak
toInnerArc
:This would produce 2 benefits:
Arc
is guaranteed to be the size of a single pointer, which is cool. Also, being more realistic, it means that if you have a non-zero-sized allocator, you don't have to pay the cost of its size on each clone of the instance, instead the allocator is stored in the inner pointer. That means that multiple copies of the same instance won't require multiple copies of the allocator, saving memory unlike the current approach,A
doesn't require implementingClone
if you want to clone theArc
, since it's stored in the shared pointer. This would relax the currentArc
cloning implementation, no longer requiringA: Allocator + Clone
but onlyA: Allocator
. It would probably relax the same constrain inmake_mut
,unwrap_or_clone
,downcast
,downcast_unchecked
,From<Vec<T, A>> for Arc<[T], A>
andTryFrom<Arc<[T], A>> for Arc<[T; N], A>
.The text was updated successfully, but these errors were encountered: