FatErasedPtr
- Dominant language
- Rust
- Stars
- 137
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
I had just fun: Type erased pointers that Drop properly:
```
pub struct FatErasedPtr {
ptr: ErasedPtr,
dropfn: fn(ErasedPtr),
}
impl From
for FatErasedPtr {
#[inline(always)]
fn from(this: P) -> Self {
fn dropfn (this: ErasedPtr) {
unsafe {
::unerase(this) };
}
FatErasedPtr {
ptr: P::erase(this),
dropfn: dropfn::
,
}
}
}
impl Drop for FatErasedPtr {
fn drop(&mut self) {
(self.dropfn)(self.ptr)
}
}
#[test]
fn faterasedptr() {
use alloc::rc::Rc;
let rc: Rc = Rc::new(123);
let fat_erased: FatErasedPtr = FatErasedPtr::from(rc);
assert_eq!(core::mem::size_of_val(&fat_erased), core::mem::size_of::()*2);
}
```
Was just a curious experiment here. I can complete that and send a PR if this is interesting.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the existing ErasablePtr and ErasedPtr APIs, then compare the proposed FatErasedPtr implementation and its faterasedptr test with the crate's current pointer utilities. Confirm whether the experiment fits the project and define acceptance criteria around proper dropping and the demonstrated size behavior before proposing a PR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100