acrolin

TylerMSFT · TylerMSFT · commit be25fe4326cc · 2023-06-19T16:49:26.000-07:00
diff --git a/docs/overview/cpp-conformance-improvements.md b/docs/overview/cpp-conformance-improvements.md
@@ -55,7 +55,7 @@ struct S
 bool b = S{} != S{};
 ```
 
-This code is accepted by the Microsoft Visual Studio C++ compiler. This means that the compiler is more strict with programs such as:
+The compiler accepts this code, which means that the compiler is more strict with code such as:
 
 ```c++
 struct S
@@ -67,7 +67,7 @@ struct S
 bool b = S{} == S{};
 ```
 
-In version 17.5 the previous program is accepted. In 17.6 it is rejected. To fix it, add `const` to `operator==` to remove the ambiguity. Or, add a corresponding `operator!=` to the definition as shown in the following example:
+Version 17.5 of the compiler accepts this program. Version 17.6 of the compiler rejects it. To fix it, add `const` to `operator==` to remove the ambiguity. Or, add a corresponding `operator!=` to the definition as shown in the following example:
 
 ```cpp
 struct S
@@ -82,7 +82,7 @@ bool b = S{} == S{};
 
 The previous program is accepted by the Microsoft Visual Studio C++ compiler versions 17.5 and 17.6, and calls `S::operator==` in both versions.
 
-The general programming model outlined in P2468R2 is that if there is a corresponding `operator!=` for a type, it will typically suppress the rewrite behavior. Adding a corresponding `operator!=` is the suggested fix for code that previously compiled in C++17. For more information, see [Programming Model](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html#programming-model).
+The general programming model outlined in P2468R2 is that if there's a corresponding `operator!=` for a type, it will typically suppress the rewrite behavior. Adding a corresponding `operator!=` is the suggested fix for code that previously compiled in C++17. For more information, see [Programming Model](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html#programming-model).
 
 ## <a name="improvements_174"></a> Conformance improvements in Visual Studio 2022 version 17.4
 
@@ -132,7 +132,7 @@ enum Changed
 
 In versions of Visual Studio before Visual Studio 2022 version 17.4, the C++ compiler didn't correctly model the types of enumerators. It could assume an incorrect type in enumerations without a fixed underlying type before the closing brace of the enumeration. Under [`/Zc:enumTypes`](../build/reference/zc-enumtypes.md), the compiler now correctly implements the standard behavior.
 
-The C++ Standard specifies that within an enumeration definition of no fixed underlying type, the types of enumerators are determined by their initializers. Or, for the enumerators with no initializer, by the type of the previous enumerator (accounting for overflow). Previously, such enumerators were always given the deduced type of the enumeration, with a placeholder for the underlying type (typically **`int`**).
+The C++ Standard specifies that within an enumeration definition of no fixed underlying type, initializers determine the types of enumerators. Or, for the enumerators with no initializer, by the type of the previous enumerator (accounting for overflow). Previously, such enumerators were always given the deduced type of the enumeration, with a placeholder for the underlying type (typically **`int`**).
 
 When enabled, the **`/Zc:enumTypes`** option is a potential source and binary breaking change. It's off by default, and not enabled by **`/permissive-`**, because the fix may affect binary compatibility. Some enumeration types change size when the conformant fix is enabled. Certain Windows SDK headers include such enumeration definitions.
 
@@ -326,9 +326,9 @@ void f()
 
 Visual Studio 2022 version 17.1 contains the following conformance improvements, bug fixes, and behavior changes in the Microsoft C/C++ compiler.
 
-### Detect ill-formed capture default in non-local lambda-expressions
+### Detect ill-formed capture default in nonlocal lambda-expressions
 
-The C++ Standard only allows a lambda expression in block scope to have a capture-default. In Visual Studio 2022 version 17.1 and later, the compiler detects when a capture default isn't allowed in a non-local lambda expression. It emits a new level 4 warning, C5253.
+The C++ Standard only allows a lambda expression in block scope to have a capture-default. In Visual Studio 2022 version 17.1 and later, the compiler detects when a capture default isn't allowed in a nonlocal lambda expression. It emits a new level 4 warning, C5253.
 
 This change is a source breaking change. It applies in any mode that uses the new lambda processor: **`/Zc:lambda`**, **`/std:c++20`**, or **`/std:c++latest`**.
 
@@ -341,7 +341,7 @@ In Visual Studio 2022 version 17.1 this code now emits an error:
 
 auto incr = [=](int value) { return value + 1; };
 
-// capture_default.cpp(3,14): error C5253: a non-local lambda cannot have a capture default
+// capture_default.cpp(3,14): error C5253: a nonlocal lambda cannot have a capture default
 // auto incr = [=](int value) { return value + 1; };
 //              ^
 ```
@@ -375,7 +375,7 @@ int main(void)
 // C4113: 'int (__cdecl *)(char *)' differs in parameter lists from 'int (__cdecl *)(int)'
 ```
 
-### Error on a non-dependent `static_assert`
+### Error on a nondependent `static_assert`
 
 In Visual Studio 2022 version 17.1 and later, if the expression associated with a `static_assert` isn't a dependent expression, the compiler evaluates the expression as soon as it's parsed. If the expression evaluates to `false`, the compiler emits an error. Previously, if the `static_assert` was within the body of a function template (or within the body of a member function of a class template), the compiler wouldn't perform this analysis.
 
