-
Notifications
You must be signed in to change notification settings - Fork 12
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
Consider to design StaticRc
as a linear type?
#7
Comments
Unfortunately, to the best of my knowledge there is no way to implement linear types in Rust, and therefore as a "placeholder" there is a In the absence of specialization and negative trait implementation, it feels to me like the only way to produce a compilation error would be to provoke a monomorphization error if Did you have another idea? Or do you know how to produce a (nice) monomorphization error? |
I have tried to introduce a static assertion in the struct Linear;
impl Drop for Linear {
fn drop(&mut self) {
const_assert!(false)
}
}
fn main() {
'a: { let _linear = Linear; } // Should not compile
'b: { let _linear = std::mem::ManuallyDrop(Linear); } // Should compile
} Unfortunately, it doesn't work because the Currently, as you say, it might only be possible to use a |
From some brief tests using the impl<T: ?Sized, const NUM: usize, const DEN: usize> Drop for StaticRc<T, NUM, DEN> {
#[inline(always)]
fn drop(&mut self) {
if NUM == DEN {
// Safety:
// - Ratio = 1, hence full ownership.
// - `self.pointer` was allocated by Box.
unsafe { Box::from_raw(self.pointer.as_ptr()) };
} else {
dont_panic::dont_panic!("Drop of incomplete StaticRc")
}
}
} And yeah, it doesn't work at all without optimizations. So you'd want to gate this on "has release optimizations", which doesn't seem too hard. Use an assertion if optimisations are disabled, use this if they are enabled and a feature is set? |
@5225225 I'd love to have a compile-time error, however shouldn't we ideally aim for an error in Debug, rather than Release? I suppose having |
Yes, but you need to use optimisations in order to use dont_panic. So I'd expect users of this crate to put a release build in their CI in addition to their debug builds (we may also want to put it behind a |
In current implementation, a
StaticRc<T, NUM, DEN>
whereNUM
<DEN
, it will do nothing onDrop
. It can probably lead to memory leak if a "full" pointer is split up to two, and the two pointers are dropped silently.How about to design the
StaticRc<T, NUM, DEN>
to be a linear type (i.e., it must be use and only use once). To say an object is fully used in the static reference counting system means: it is created as a full pointer likeBox
, and might be split up to several sub-pointers that shares the ownity, but must finally joined into a full pointer again, then the pointer is automatically dropped.So the main implementation idea is: if I drop a non-full pointer, there will be a compile-time error because it is the object is not fully used.
The text was updated successfully, but these errors were encountered: