Merge alternatives

Author: josh11b

proposals/p5434.md

@@ -43,8 +43,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 -   [Alternatives considered](#alternatives-considered)
     -   [No `ref`, only pointers](#no-ref-only-pointers)
     -   [Remove pointers after adding references](#remove-pointers-after-adding-references)
-    -   [References in the type system](#references-in-the-type-system)
-        -   [Allow `ref` bindings in the fields of classes](#allow-ref-bindings-in-the-fields-of-classes)
+    -   [Allow `ref` bindings in the fields of classes](#allow-ref-bindings-in-the-fields-of-classes)
     -   [No call-site annotation](#no-call-site-annotation)
     -   [Top-level `ref` introducer](#top-level-ref-introducer)
     -   [`ref` as a type qualifier](#ref-as-a-type-qualifier)
@@ -1097,14 +1096,7 @@ One of the features of a reference is what it cannot do, and we would have to
 remove those restrictions to be able to satisfy the pointer use cases with
 references.
 
-### References in the type system
-
-C++ includes references in its object type system, but not as the type of
-expressions. The main downside to this is that references end up having a number
-of limitations and rules that other types don't have, such as there are no
-references of references.
-
-#### Allow `ref` bindings in the fields of classes
+### Allow `ref` bindings in the fields of classes
 
 A type with reference binding fields would need a lot of restrictions since
 reference bindings are not assignable. We did not see enough motivation to put
@@ -1155,6 +1147,9 @@ but tuples already can't represent `var` or compile-time parameters. We have
 other plans for this, instead of trying to stretch tuples to encompass these use
 cases.
 
+We also noted that including references in the type system led to a number of
+inconsistencies in C++, such as no there not being references of references.
+
 ### `bound` would change the default return to `let`
 
 We considered saying that `bound` would change the default return to use the