On Fri, Jun 26, 2026 at 8:36 PM Danilo Krummrich <[email protected]> wrote: > > Add a new ForLt trait as a base for CovariantForLt: > > - ForLt (non-unsafe): represents a type generic over a lifetime, with > no covariance guarantee. > > - CovariantForLt (unsafe): becomes a subtrait of ForLt that > additionally proves the type is covariant over its lifetime > parameter, providing a safe cast_ref() method. > > This split allows non-covariant types (e.g. types behind a Mutex) to > implement ForLt and participate in DevresLt / registration data patterns > that use HRTB closures for sound access, without requiring a covariance > proof that would fail to compile. > > Both macros share the UnsafeForLtImpl helper type, distinguished by > a const generic N: ForLt! emits N = 0 (no covariance proof), > CovariantForLt! emits N = 1 (with compile-time covariance proof). > > Signed-off-by: Danilo Krummrich <[email protected]>
If this goes in at the same time as the move (as I assume), then am I understanding it right that if someone else was using `ForLt` (trait/macro) things would either break at compile-time (which is OK) or, in the covariant type case with no `cast_ref()`, it would build, but someone could in principle have relied on `ForLt` providing the covariance guarantee in unsafe code? Acked-by: Miguel Ojeda <[email protected]> We could take the chance to add some missing intra-doc links, but I can add a good first issue. Thanks! Cheers, Miguel
