Autoref/autoderef

Author: Mark-Simulacrum

src/SUMMARY.md

@@ -9,3 +9,4 @@
 - [Proposing a new project](./proposing_a_project.md)
 - [Design notes](./design_notes.md)
   - [Allowing integer literals like `1` to be inferred to floating point](./design_notes/int_literal_as_float.md)
+  - [Autoderef and autoref in operators](./design_notes/autoref_ops.md)

src/design_notes/autoref_ops.md

@@ -0,0 +1,29 @@
+# Autoref/Autoderef in operators
+
+Rust permits overriding most of the operators (e.g., `+`, `-`, `+=`). In part
+due to `Copy` types not auto-dereferencing, it is common to have `T + &T` or `&T
++ &T`, with potentially many levels of indirection on either side of the
+operator.
+
+There is desire in general to avoid needing to both add impls for referenced
+versions of types because they:
+
+- bloat documentation
+- are never quite sufficient (always more references are possible)
+- can cause inference regressions, as the compiler cannot in general know that
+  `&T + &T` is equivalent to `u64 + u64`.
+
+## History
+
+The standard library initially had just the basic impls of the operator traits
+(e.g., `impl Add<u64> for u64`) but has since gained `&u64 + &u64`, `u64 + &u64`
+and `&u64 + u64`. These impls usually cause some amount of inference breakage in
+practice.
+
+Especially with non-Copy types (for example bigints), forcing users to add references can be
+increasingly verbose: `&u * &(&(&u.square() + &(&a * &u)) + &one)`, for example.
+
+There have also been a number of discussions on RFCs and issues, including:
+- [Rust tracking issue #44762](https://github.com/rust-lang/rust/issues/44762)
+    - This includes some implementation/mentoring notes.
+- [RFC 2147](https://github.com/rust-lang/rfcs/pull/2147)