Incorporated feedback

Author: Daniel Parvin

standard/classes.md

@@ -1089,7 +1089,7 @@ A type declared within a class or struct is called a ***nested type***. A type t
 
 #### 15.3.9.2 Fully qualified name
 
-The fully qualified name ([§7.8.3](basic-concepts.md#783-fully-qualified-names)) for a nested type declaration is `S.N` where `S` is the fully qualified name of the type declarationin which type `N` is declared and `N` is the unqualified name ([§7.8.2](basic-concepts.md#782-unqualified-names)) of the nested type declaration (including any *generic_dimension_specifier* ([§12.8.18](expressions.md#12817-the-typeof-operator))).
+The fully qualified name ([§7.8.3](basic-concepts.md#783-fully-qualified-names)) for a nested type declaration is `S.N` where `S` is the fully qualified name of the type declaration in which type `N` is declared and `N` is the unqualified name ([§7.8.2](basic-concepts.md#782-unqualified-names)) of the nested type declaration (including any *generic_dimension_specifier* ([§12.8.18](expressions.md#12817-the-typeof-operator))).
 
 #### 15.3.9.3 Declared accessibility
 
@@ -3837,7 +3837,7 @@ Once a particular non-ref-valued property or non-ref-valued indexer has been sel
 >
 > *end example*
 
-Once a particular ref-valued property or ref-valued indexer has been selected--whether the usage is as a value, the target of a simple assignment, or the target of a compound assignment--the accessibility domain of the get accessor involved is used to determine if that usage is valid.
+Once a particular ref-valued property or ref-valued indexer has been selected---whether the usage is as a value, the target of a simple assignment, or the target of a compound assignment---the accessibility domain of the get accessor involved is used to determine if that usage is valid.
 
 An accessor that is used to implement an interface shall not have an *accessor_modifier*. If only one accessor is used to implement an interface, the other accessor may be declared with an *accessor_modifier*:
 
@@ -4521,7 +4521,7 @@ binary_operator_declarator
 
 overloadable_binary_operator
     : '+'  | '-'  | '*'  | '/'  | '%'  | '&' | '|' | '^'  | '<<' 
-    | '>>' | '==' | '!=' | '>' | '<' | '>=' | '<='
+    | right_shift | '==' | '!=' | '>' | '<' | '>=' | '<='
     ;
 
 conversion_operator_declarator

standard/conversions.md

@@ -661,8 +661,8 @@ Once a most-specific user-defined conversion operator has been identified, the a
 Evaluation of a user-defined conversion never involves more than one user-defined or lifted conversion operator. In other words, a conversion from type `S` to type `T` will never first execute a user-defined conversion from `S` to `X` and then execute a user-defined conversion from `X` to `T`.
 
 - Exact definitions of evaluation of user-defined implicit or explicit conversions are given in the following subclauses. The definitions make use of the following terms:
-- If a standard implicit conversion ([§10.4.2](conversions.md#1042-standard-implicit-conversions)) exists from a type `A` to a type `B`, and if neither `A` nor `B` are *interface_type* `S`, then `A` is said to be ***encompassed by*** `B`, and `B` is said to ***encompass*** `A`.
-- If a standard implicit conversion ([§10.4.2](conversions.md#1042-standard-implicit-conversions)) exists from an expression `E` to a type `B`, and if neither `B` nor the type of `E` (if it has one) are *interface_type* `S`, then `E` is said to be *encompassed by* `B`, and `B` is said to *encompass* `E`.
+- If a standard implicit conversion ([§10.4.2](conversions.md#1042-standard-implicit-conversions)) exists from a type `A` to a type `B`, and if neither `A` nor `B` are *interface_type*s, then `A` is said to be ***encompassed by*** `B`, and `B` is said to ***encompass*** `A`.
+- If a standard implicit conversion ([§10.4.2](conversions.md#1042-standard-implicit-conversions)) exists from an expression `E` to a type `B`, and if neither `B` nor the type of `E` (if it has one) are *interface_type*s, then `E` is said to be *encompassed by* `B`, and `B` is said to *encompass* `E`.
 - The ***most-encompassing type*** in a set of types is the one type that encompasses all other types in the set. If no single type encompasses all other types, then the set has no most-encompassing type. In more intuitive terms, the most-encompassing type is the “largest” type in the set—the one type to which each of the other types can be implicitly converted.
 - The ***most-encompassed type*** in a set of types is the one type that is encompassed by all other types in the set. If no single type is encompassed by all other types, then the set has no most-encompassed type. In more intuitive terms, the most-encompassed type is the “smallest” type in the set—the one type that can be implicitly converted to each of the other types.
 

standard/expressions.md

@@ -156,9 +156,9 @@ The precedence of an operator is established by the definition of its associated
 > |  [§12.12](expressions.md#1212-relational-and-type-testing-operators)             | Equality                         | `==` `!=` |
 > |  [§12.13](expressions.md#1213-logical-operators)             | Logical AND                      | `&`  |
 > |  [§12.13](expressions.md#1213-logical-operators)             | Logical XOR                      | `^`  |
-> |  [§12.13](expressions.md#1213-logical-operators)             | Logical OR                       | <code>&#124;</code>  |
+> |  [§12.13](expressions.md#1213-logical-operators)             | Logical OR                       | `\|`  |
 > |  [§12.14](expressions.md#1214-conditional-logical-operators)             | Conditional AND                  | `&&`  |
-> |  [§12.14](expressions.md#1214-conditional-logical-operators)             | Conditional OR                   | <code>&#124;&#124;</code>  |
+> |  [§12.14](expressions.md#1214-conditional-logical-operators)             | Conditional OR                   | `\|\|`  |
 > |  [§12.15](expressions.md#1215-the-null-coalescing-operator) and [§12.16](expressions.md#1216-the-throw-expression-operator)             | Null coalescing and throw expression                  | `??`  `throw x`  |
 > |  [§12.18](expressions.md#1218-conditional-operator)             | Conditional                      | `?:`   |
 > |  [§12.21](expressions.md#1221-assignment-operators) and [§12.19](expressions.md#1219-anonymous-function-expressions)  | Assignment and lambda expression | `=` `= ref` `*=` `/=` `%=` `+=` `-=` `<<=` `>>=` `&=` `^=` `\|=` `=>`   |
@@ -2661,8 +2661,7 @@ A collection initializer consists of a sequence of element initializers, enclose
 
 The collection object to which a collection initializer is applied shall be of a type that implements `System.Collections.IEnumerable` or a compile-time error occurs. For each specified element in order from left to right, normal member lookup is applied to find a member named `Add`. If the result of the member lookup is not a method group, a compile-time error occurs. Otherwise, overload resolution is applied with the expression list of the element initializer as the argument list, and the collection initializer invokes the resulting method. Thus, the collection object shall contain an applicable instance or extension method with the name `Add` for each element initializer.
 
-> *Example*:
-> The following shows a class that represents a contact with a name and a list of phone numbers, and the creation and initialization of a `List<Contact>`:
+> *Example*: The following shows a class that represents a contact with a name and a list of phone numbers, and the creation and initialization of a `List<Contact>`:
 >
 > <!-- Example: {template:"standalone-lib", name:"CollectionInitializers2"} -->
 > ```csharp