Nits

Author: jnm2

standard/types.md

@@ -1046,11 +1046,11 @@ A compiler may use any expression that dereferences a variable, property, or eve
 
 #### 8.9.5.2 Type conversions
 
-For the purpose of determining whether a conversion is *permitted*, a compiler must consider every nullable-annotated type to be equivalent to its unannotated version. The compiler may however issue warnings if the annotations of the types are not compatible.
+For the purpose of determining whether a conversion is *permitted*, a compiler must consider every nullable-annotated type to be equivalent to its unannotated version. A compiler may issue warnings if the annotations of the types are not compatible.
 
 (examples: `List<string>` to `IEnumerable<object?>`, or `List<string?>?` to `IEnumerable<object>`, ...)
 
-A compiler may follow rules for interface variance ([§18.2.3.3](interfaces.md#18233-variance-conversion)), delegate variance ([§20.4](delegates.md#204-delegate-compatibility)), and array covariance ([§1.7.6](arrays.md#176-array-covariance)) in determining whether to issue a warning for type conversions. 
+A compiler may follow rules for interface variance ([§18.2.3.3](interfaces.md#18233-variance-conversion)), delegate variance ([§20.4](delegates.md#204-delegate-compatibility)), and array covariance ([§1.7.6](arrays.md#176-array-covariance)) in determining whether to issue a warning for type conversions.
 (Do we need to list each type here? E.g. tuple types...)
 
 > <!-- Example: {template:"code-in-class-lib", name:"NullVariance"} -->
@@ -1095,7 +1095,7 @@ A compiler may follow rules for interface variance ([§18.2.3.3](interfaces.md#1
 >
 > *end example*
 
-Types that are invariant likewise may produce a warning when the conversion differs only in the nullability of type arguments.
+A compiler may issue a warning when nullability differs in either direction in types which do not permit a variant conversion.
 
 > <!-- Example: {template:"code-in-class-lib", name:"NullInvariance"} -->
 > ```csharp