Idea for making Rc more leak-safe

[pepp]

After reading Niko’s excellent article about reference counting, leaks and scoped threads I like the closure-based scoped threads the best.

However, in the section about the proposed Leak trait being somewhat contagious I got this somewhat unrelated idea how to lower the risk of introducing leak-related bugs: Extend type parameter constrains syntax with | (or) operator and define Rc as struct Rc<T: !Drop | (Drop + Leak)>. So types that implement Drop but do not opt-in to Leak would not be possible in Rc as they are likely to introduce bugs in case of cycles.

Pros: type system will catch some more errors. Cons: Type that implements Drop but not Leak cannot be used with Rc even in cases where cycles cannot happen. Maybe this could be improved in the future by automatically implemented trait Acyclic for types that do not form cycles in type composition graph so Rc would be struct Rc<T: Acyclic | !Drop | (Drop + Weak)>.

Alternatively, if specializations are possible the Rc could be defined as struct Rc<T : Leakable> and Leakable as

trait Leakable<T : !Drop> {}
trait Leakable<T : Drop + Leak> {}

[Gankra]

Leak is being proposed as an Opt-In-Built-In-Trait that defaults to “yes, I can be leaked”. As such all types would by default satisfy the Rc bounds. I’m pretty sure that this would not reduce the Leak contagion, it would exacerbate it. All trait bounds would grow from Blah<Trait+Leak> to Blah<Trait+(!Drop | (Drop + Leak))>.

Further, if you do a bit of algebra:

!D or (D and L)          ===
(!D or D) and (!D or L)  ===
TRUE and (!D or L)       ===
!D or L

every type that is !Drop is by definition safe to leak so !D -> L. Therefore we just end up with:

L

So this more complex bound is simply Leak.

[pepp]

Fair enough. I failed to realize that !Drop is trivially also Leak.