design/43651-type-parameters: minor formatting/wording fixes Change-Id: I3eba2d2d24c23d8c9e371ea1a123be32ae84cbaa Reviewed-on: https://go-review.googlesource.com/c/proposal/+/352114 Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

diff --git a/design/43651-type-parameters.md b/design/43651-type-parameters.md
index 77e9b43..89b78cf 100644
--- a/design/43651-type-parameters.md
+++ b/design/43651-type-parameters.md

@@ -1893,8 +1893,6 @@
 
 Let's return now to type sets to cover some less important details
 that are still worth noting.
-These are not additional rules or concepts, but are consequences of
-how type sets work.
 
 #### Both elements and methods in constraints
 
@@ -1906,7 +1904,7 @@
 // type that is both 1) defined as a signed integer type;
 // 2) has a String method.
 type StringableSignedInteger interface {
-	~int | ~int8 | ~int16 | ~int32| ~int64
+	~int | ~int8 | ~int16 | ~int32 | ~int64
 	String() string
 }
 ```
@@ -2853,7 +2851,7 @@
 
 An earlier draft design of generics implemented constraints using a
 new language construct called contracts.
-Type sets appeared only in contracts, rather than on interface types.
+Type sets appeared only in contracts, rather than in interface types.
 However, many people had a hard time understanding the difference
 between contracts and interface types.
 It also turned out that contracts could be represented as a set of
@@ -3779,7 +3777,7 @@
 		lst.head = &element[T]{val: v}
 		lst.tail = lst.head
 	} else {
-		lst.tail.next = &element[T]{val: v }
+		lst.tail.next = &element[T]{val: v}
 		lst.tail = lst.tail.next
 	}
 }
@@ -4210,7 +4208,7 @@
 
 ```
 type Pair[T any] struct { f1, f2 T }
-var V = Pair{1, 2} // inferred as Pair(int){1, 2}
+var V = Pair{1, 2} // inferred as Pair[int]{1, 2}
 ```
 
 It's not clear how often this will arise in real code.