On Mon, Jun 1, 2026 at 3:24 PM Philipp Stanner <[email protected]> wrote: > > On Mon, 2026-06-01 at 15:22 +0200, Alice Ryhl wrote: > > On Mon, Jun 1, 2026 at 2:47 PM Philipp Stanner <[email protected]> wrote: > > > > > > On Mon, 2026-06-01 at 12:39 +0000, Alice Ryhl wrote: > > > > On Mon, Jun 01, 2026 at 02:26:17PM +0200, Philipp Stanner wrote: > > > > > On Mon, 2026-06-01 at 10:36 +0000, Alice Ryhl wrote: > > > > > > On Sat, May 30, 2026 at 04:35:11PM +0200, Philipp Stanner wrote: > > > > > > > +/// A trait to enforce that all data in a [`DriverFence`] either > > > > > > > does not need > > > > > > > +/// drop, or lives in a [`RcuBox`]. > > > > > > > +pub trait DriverFenceAllowedData: private::Sealed {} > > > > > > > + > > > > > > > +mod private { > > > > > > > + pub trait Sealed {} > > > > > > > +} > > > > > > > + > > > > > > > +impl<F: Copy> DriverFenceAllowedData for F {} > > > > > > > +impl<F: Send> DriverFenceAllowedData for RcuBox<F> {} > > > > > > > + > > > > > > > +impl<F: Copy> private::Sealed for F {} > > > > > > > +impl<F: Send> private::Sealed for RcuBox<F> {} > > > > > > > > > > > > Why sealed? Just make the trait unsafe and require the things you > > > > > > require from the user. > > > > > > > > > > This is far better. We definitely only allow the user to pass A or B, > > > > > and only then it compiles. > > > > > > > > What if I have another type that I want to use here? For example, maybe > > > > I have a struct containing a copy field and an RcuBox. Or maybe I have > > > > an ARef<_> of some C type that uses rcu for cleanup. Then I must edit > > > > this file to add support for it? > > > > > > > > > The unsafe implementation could be messed up. > > > > > > > > > > I thought that's what Sealed is for. Or isn't it? > > > > > > > > Sealed is for making 100% sure that downstream crates/drivers cannot > > > > provide their own implementations. But I don't see why you need that. > > > > All you require is that the value remains valid for one grace period > > > > after cleanup begins. As long as the type satisfies that, you are happy. > > > > An unsafe trait can require that sort of requirement from the user. > > > > > > > > I think what you want is expressed well by `RcuFreeSafe` from this > > > > thread: > > > > https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/Consolidate.20.60PollCondVarBox.60.20into.20.60Rcu.2ABox.60/near/598726724 > > > > > > > > > > I guess this is a question of design principles. If you demand an > > > RcuBox, you have a guarantee that it's safe. > > > > > > If you demand an unsafe trait, you open the possibility for people > > > messing up. > > > > > > Due to the unsafe-contract you'd have moved the responsibility for the > > > soundness to the driver. > > > > > > I would not want to block your suggestion, but I am not sure whether > > > that's really the better design idea. > > > > Yes, it's a design principle. You are saying that if someone needs to > > do X but might get it wrong, we should take away the ability to do X? > > I fundamentally disagree with that principle. Unsafe traits is the > > tool Rust created for the exact problem you have; marking places where > > you should be careful is the entire point of 'unsafe'. > > I mean, fine by me if the others don't disagree. > > But when then do you ever really want a Sealed trait?
Sealed traits are a very niche feature. The main use-case is forwards-compatibility. It's not a breaking change to add a new method to a sealed trait because no downstream crates could implement the trait. Alice
