C/C++ -> C and C++ (#2340)

As requested at https://github.com/carbon-language/carbon-lang/pull/2332#discussion_r1002257672, "Very minor, but "C/C++" irritates some people in the C++ community so we may as well avoid it here."

docs/design/README.md

@@ -3192,7 +3192,7 @@ available to C++ and a subset of C++ APIs will be available to Carbon.
 
 > References:
 >
-> -   [Bidirectional interoperability with C/C++](interoperability/README.md)
+> -   [Bidirectional interoperability with C and C++](interoperability/README.md)
 > -   Proposal
 >     [#175: C++ interoperability goals](https://github.com/carbon-language/carbon-lang/pull/175)
 

docs/design/classes.md

@@ -2106,7 +2106,7 @@ the type of `U.x`."
 -   [#257: Initialization of memory and variables](https://github.com/carbon-language/carbon-lang/pull/257)
 
     -   [Require compile-time-proven initialization](/proposals/p0257.md#require-compile-time-proven-initialization)
-    -   [C/C++ uninitialized](/proposals/p0257.md#cc-uninitialized)
+    -   [C and C++ uninitialized](/proposals/p0257.md#c-and-c-uninitialized)
     -   [Allow passing unformed objects to parameters or returning them?](/proposals/p0257.md#allow-passing-unformed-objects-to-parameters-or-returning-them)
     -   [Allow assigning an unformed object to another unformed object?](/proposals/p0257.md#allow-assigning-an-unformed-object-to-another-unformed-object)
     -   [Fully destructive move (Rust)](/proposals/p0257.md#fully-destructive-move-rust)

docs/design/interoperability/README.md

@@ -1,4 +1,4 @@
-# Bidirectional interoperability with C/C++
+# Bidirectional interoperability with C and C++
 
 <!--
 Part of the Carbon Language project, under the Apache License v2.0 with LLVM

docs/design/metaprogramming.md

@@ -29,4 +29,4 @@ context -- that proposal may replace this.
 
 Carbon provides metaprogramming facilities that look similar to regular Carbon
 code. These are structured, and do not offer inclusion or arbitrary
-preprocessing of source text such as C/C++ does.
+preprocessing of source text such as C and C++ do.

docs/project/difficulties_improving_cpp.md

@@ -24,7 +24,7 @@ to complex syntax with
 
 **C++ has also prioritized backwards compatibility** including both syntax and
 [ABI](https://en.wikipedia.org/wiki/Application_binary_interface). This is
-heavily motivated by preserving its access to existing C/C++ ecosystems, and
+heavily motivated by preserving its access to existing C and C++ ecosystems, and
 forms one of the foundations of common Linux package management approaches. A
 consequence is that rather than changing or replacing language designs to
 simplify and improve the language, features have overwhelmingly been added over

explorer/ast/value_category.h

@@ -11,9 +11,9 @@ namespace Carbon {
 // to a variable or a value. A variable can be mutated, and can have its
 // address taken, whereas a value cannot.
 enum class ValueCategory {
-  // A variable. This roughly corresponds to a C/C++ lvalue.
+  // A variable. This roughly corresponds to a C++ lvalue.
   Var,
-  // A value. This roughly corresponds to a C/C++ rvalue.
+  // A value. This roughly corresponds to a C++ rvalue.
   Let,
 };
 

proposals/p0257.md

@@ -34,7 +34,7 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
         -   [Trivially required initialization, with no escape hatch](#trivially-required-initialization-with-no-escape-hatch)
         -   [Initialize on all branches prior to use (Rust, C#, TypeScript)](#initialize-on-all-branches-prior-to-use-rust-c-typescript)
         -   [Definitive initialization (Swift)](#definitive-initialization-swift)
-    -   [C/C++ uninitialized](#cc-uninitialized)
+    -   [C and C++ uninitialized](#c-and-c-uninitialized)
     -   [Allow passing unformed objects to parameters or returning them?](#allow-passing-unformed-objects-to-parameters-or-returning-them)
     -   [Allow assigning an unformed object to another unformed object?](#allow-assigning-an-unformed-object-to-another-unformed-object)
     -   [Fully destructive move (Rust)](#fully-destructive-move-rust)
@@ -725,7 +725,7 @@ Disadvantages:
 -   Would still need a semantic model for moved from objects which would
     introduce some amount of additional complexity.
 
-### C/C++ uninitialized
+### C and C++ uninitialized
 
 We could pursue the same approach as C and C++ here. However, this path has
 proven to have severe problems. It has inevitably resulted in prevalent bugs and
@@ -734,8 +734,8 @@ variables in the language makes teaching the debug build to catch these bugs
 extremely difficult and potentially impossible. We essentially will need
 developers to heavily use an MSan-like mode (either by integrating it with the
 debug build or having a separate one) in order to cope with the bugs caused by
-uninitialized memory. This is the only thing that has allowed coping with C/C++
-semantics here and even it is not very effective.
+uninitialized memory. This is the only thing that has allowed coping with C and
+C++ semantics here and even it is not very effective.
 
 If MSan remains a separate tool that needs propagation and origin tracking
 ([details](https://research.google.com/pubs/archive/43308.pdf)), the cost and

proposals/p0285.md

@@ -91,8 +91,8 @@ A few syntaxes that are likely to influence `if`/`else` are:
 
 ## Proposal
 
-We should make `if`/`else` syntax consistent with C/C++, rather than adopting
-the syntax of another language.
+We should make `if`/`else` syntax consistent with C and C++, rather than
+adopting the syntax of another language.
 
 ## Details
 

proposals/p0339.md

@@ -428,7 +428,7 @@ have them) are:
 | Java         | 11% | Python     | 16% | Java        | 17% | Python     |
 | Python       | 11% | Java       | 11% | JavaScript  |  8% | Java       |
 | C++          |  7% | Go         |  8% | C#          |  7% | TypeScript |
-| C#           |  4% | C++        |  7% | C/C++       |  7% | C#         |
+| C#           |  4% | C++        |  7% | C and C++   |  7% | C#         |
 | Visual Basic |  4% | Ruby       |  7% | PHP         |  6% | PHP        |
 | JavaScript   |  2% | TypeScript |  7% | R           |  4% | C++        |
 | PHP          |  2% | PHP        |  6% | Objective-C |  4% | C          |

proposals/p0340.md

@@ -108,8 +108,8 @@ similar in many languages, even if details may change.
 
 ## Proposal
 
-Carbon should adopt `while` loop syntax consistent with C/C++. In particular, it
-should adopt these three kinds of statements:
+Carbon should adopt `while` loop syntax consistent with C and C++. In
+particular, it should adopt these three kinds of statements:
 
 -   `while`: declares that we're doing a loop, containing the condition.
 -   `continue`: continues with the next loop iteration, starting with the loop
@@ -137,7 +137,7 @@ starting with the condition being tested.
 
 `break` exits the loop immediately, without testing the condition.
 
-All of this is consistent with C/C++ behavior.
+All of this is consistent with C and C++ behavior.
 
 ### Executable semantics form
 

proposals/p0353.md

@@ -143,7 +143,7 @@ other statements in the loop body.
 
 `break` exits the loop immediately.
 
-All of this is consistent with C/C++ behavior.
+All of this is consistent with C and C++ behavior.
 
 ### Range inputs