Project import generated by Copybara.

PiperOrigin-RevId: 503164845
Change-Id: I75045c85d12a8e373d46d6766675e645b70a580c

Author: Protocol Buffer Team

content/programming-guides/api.md

@@ -652,12 +652,12 @@ message PhotoEnhancement {
 message PhotoEnhancementReply {
   // Good: PhotoEnhancement can grow to describe enhancements that require
   // more fields than just an enum.
-  repeated PhotoEnhancement enhancement;
+  repeated PhotoEnhancement enhancements;
 
   // Bad: If we ever want to return parameters associated with the
   // enhancement, we'd have to introduce a parallel array (terrible) or
   // deprecate this field and introduce a repeated message.
-  repeated EnhancementType enhancement_type;
+  repeated EnhancementType enhancement_types;
 }
 ```
 
@@ -888,9 +888,9 @@ pass the two related fields around inside your own service.
 message BatchEquationSolverResponse {
   // Bad: Solved values are returned in the order of the equations given in
   // the request.
-  repeated double solved_value;
-  // (Usually) Bad: Parallel array for solved_value.
-  repeated double solved_complex_value;
+  repeated double solved_values;
+  // (Usually) Bad: Parallel array for solved_values.
+  repeated double solved_complex_values;
 }
 
 // Good: A separate message that can grow to include more fields and be
@@ -899,7 +899,7 @@ message BatchEquationSolverResponse {
 message BatchEquationSolverResponse {
   // Deprecated, this will continue to be populated in responses until Q2
   // 2014, after which clients must move to using the solutions field below.
-  repeated double solved_value [deprecated = true];
+  repeated double solved_values [deprecated = true];
 
   // Good: Each equation in the request has a unique identifier that's
   // included in the EquationSolution below so that the solutions can be

content/programming-guides/encoding.md

@@ -387,9 +387,8 @@ as Protoscope text,
 6: {3 270 86942}
 ```
 
-Only repeated fields of primitive numeric types (types) can be declared
-"packed". These are types that would normally use the `VARINT`, `I32`, or `I64`
-wire types.
+Only repeated fields of primitive numeric types can be declared "packed". These
+are types that would normally use the `VARINT`, `I32`, or `I64` wire types.
 
 Note that although there's usually no reason to encode more than one key-value
 pair for a packed repeated field, parsers must be prepared to accept multiple

content/programming-guides/proto3.md

@@ -1065,9 +1065,11 @@ language in the relevant [API reference](/reference/).
     ```c++
     SampleMessage message;
     message.set_name("name");
-    CHECK(message.has_name());
-    message.mutable_sub_message();   // Will clear name field.
-    CHECK(!message.has_name());
+    CHECK_EQ(message.name(), "name");
+    // Calling mutable_sub_message() will clear the name field and will set
+    // sub_message to a new instance of SubMessage with none of its fields set.
+    message.mutable_sub_message();
+    CHECK(message.name().empty());
     ```
 
 *   If the parser encounters multiple members of the same oneof on the wire,
@@ -1103,7 +1105,7 @@ language in the relevant [API reference](/reference/).
     msg2.mutable_sub_message();
     msg1.swap(&msg2);
     CHECK(msg1.has_sub_message());
-    CHECK(msg2.has_name());
+    CHECK_EQ(msg2.name(), "name");
     ```
 
 ### Backwards-compatibility issues

content/programming-guides/style.md

@@ -102,7 +102,10 @@ enum FooBar {
 
 Each enum value should end with a semicolon, not a comma. Prefer prefixing enum
 values instead of surrounding them in an enclosing message. The zero value enum
-should have the suffix `UNSPECIFIED`.
+should have the suffix `UNSPECIFIED`, because a server or application that gets
+an unexpected enum value will mark the field as unset in the proto instance. The
+field accessor will then return the default value, which for enum fields is the
+first enum value.
 
 ## Services {#services}