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.
