From 51f93343c83d04c602dd05971b28fd64ecfb9c23 Mon Sep 17 00:00:00 2001
From: Jules Bertholet <julesbertholet@quoi.xyz>
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 <julesbertholet@quoi.xyz>
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.