Question: Why not T: ?Sized?

[simnalamburt]

Currently, circ users can still use it with !Sized types, albeit a bit inconveniently, by coding like AtomicRc<Box<T>>. If the fat pointer is bothersome, AtomicRc<ThinBox<T>> could be used instead. It would be more convenient if circ handled this automatically. Is there a specific reason circ only supports Sized types?

(This is probably a question I could answer by reading the code, but I haven’t had a chance to look into it deeply. Sorry, haha ;) )

[powergee]

I believe you're right; it should be possible to relax the type restriction by allowing ?Sized. Additionally, I think using ThinBox for pointer tagging may not be necessary since we can still determine the available width of the low bits statically (see low_bits<T>()), similar to what crossbeam-epoch does.

This library started as a proof-of-concept implementation of the original paper, and at that time, we did not consider unsized types. I believe it's now time to support them for broader applicability, as well as for cross-type tracing (#4).

[simnalamburt]

That sounds great. Making it more user-friendly like this will not only increase the value of the research results but also raise more awareness about Safe Memory Reclamation. SMR research has made tremendous progress, but we need to address the current situation where developers are still resorting to using std::sync::Arc.