From 51f93343c83d04c602dd05971b28fd64ecfb9c23 Mon Sep 17 00:00:00 2001 From: Jules Bertholet Date: Mon, 13 Nov 2023 16:28:18 -0500 Subject: [PATCH 1/2] Update auto traits design notes with recent discussion --- src/design_notes/auto_traits.md | 32 +++++++++++++++++++++++++++----- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/src/design_notes/auto_traits.md b/src/design_notes/auto_traits.md index 59c6e48..f512f07 100644 --- a/src/design_notes/auto_traits.md +++ b/src/design_notes/auto_traits.md @@ -14,9 +14,10 @@ Auto traits are tracked in [rust-lang/rust#13231], and are also sometimes referred to as OIBITs ("opt-in built-in traits"). As of November 2020, the language team feels that new auto traits are unlikely -to be added or stabilized. See [discussion][freeze discussion] on the addition of `Freeze` for -context. There is a fairly high burden to doing so on the ecosystem, as it -becomes a concern of every library author whether to implement the trait or not. +to be added or stabilized. See [discussion][freeze discussion] on the addition +of `Freeze` for context. There is a fairly high burden to doing so on the +ecosystem, as it becomes a concern of every library author whether to implement +the trait or not. Each auto trait represents a semver compatibility hazard for Rust libraries, as adding private fields can remove the auto trait unintentionally from a type. @@ -30,8 +31,29 @@ impl !NoString for String {} ``` This is not something we generally want to allow, as it makes almost any change -to types semver breaking. That means that stabilizing defining new auto traits is -currently unlikely. +to types semver breaking. That means that stabilizing defining new auto traits +with no restrictions on negative impls is currently unlikely. + +## Restrictions on negative impls + +Not all use-cases for auto traits require unrestricted "type absence testing" +capabilities. `pyo3`'s [`Ungil` trait][Ungil] provides a good case study. `pyo3` +is a Python interoperability library, and it uses the `Ungil` trait to denote +types that are safe to access when the Python Global Interpeter Lock (GIL) is +not held. `pyo3` provides explicit `!Ungil` impls only for types defined in the +`pyo3` crate itself. Because of this, all types that do not implement `Ungil` +are defined either by `pyo3` itself, or by downstream dependencies of `pyo3`. As +long as `pyo3` does not introduce new negative impls for existing types in new +minor versions of itself, there is no backward compatibility hazard. + +`obj2c` uses its [`AutoreleaseSafe` auto trait][AutoreleaseSafe] in a similar +manner. + +[As of October 2023][2020-10-03 triage meeting], the lang team no longer feels +that stabilizing any form of auto traits is entirely out of the question. [rust-lang/rust#13231]: https://github.com/rust-lang/rust/issues/13231 [freeze discussion]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Freeze.20stabilization.20and.20auto-trait.20backcompat/near/214251682 +[Ungil]: https://docs.rs/pyo3/0.20.0/pyo3/marker/trait.Ungil.html +[AutoreleaseSafe]: https://docs.rs/objc2/latest/objc2/rc/trait.AutoreleaseSafe.html] +[2020-10-03 triage meeting]: https://hackmd.io/tRjWZXdJQyOoD1d9rLeRGQ?view#%E2%80%9CPrepare-removal-of-auto-trait-syntax-in-favor-of-new-attribute-rustc_auto_trait%E2%80%9D-rust116126 From 7f3d8fcfa23352da50443d6c66acb2429dc36c0c Mon Sep 17 00:00:00 2001 From: Jules Bertholet Date: Wed, 6 Dec 2023 00:30:52 -0500 Subject: [PATCH 2/2] Discuss trait objects --- src/design_notes/auto_traits.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/design_notes/auto_traits.md b/src/design_notes/auto_traits.md index f512f07..506ccb1 100644 --- a/src/design_notes/auto_traits.md +++ b/src/design_notes/auto_traits.md @@ -44,10 +44,17 @@ not held. `pyo3` provides explicit `!Ungil` impls only for types defined in the `pyo3` crate itself. Because of this, all types that do not implement `Ungil` are defined either by `pyo3` itself, or by downstream dependencies of `pyo3`. As long as `pyo3` does not introduce new negative impls for existing types in new -minor versions of itself, there is no backward compatibility hazard. +minor versions of itself, the backward compatibility hazard is mostly avoided. + +However, there is still one problematic case. Trait objects only implement the +traits they list explicitly, so even with the restrictions described previously, +downstream crates would be able to test for the presence of trait objects inside +upstream types. One potential solution is to change `dyn Trait` to mean +`dyn Trait + AllAutoTraitsDefinedInDownstreamCrates` or +`dyn Trait + AllAutoTraitsDefinedOutsideOfCore`. `obj2c` uses its [`AutoreleaseSafe` auto trait][AutoreleaseSafe] in a similar -manner. +manner to `pyo3`'s `Ungil`. [As of October 2023][2020-10-03 triage meeting], the lang team no longer feels that stabilizing any form of auto traits is entirely out of the question.