Values, variables, pointers, and references

docs/design/README.md

@@ -399,7 +399,7 @@ Some values, such as `()` and `{}`, may even be used as types, but only act like
 types when they are in a type position, like after a `:` in a variable
 declaration or the return type after a `->` in a function declaration. Any
 expression in a type position must be
-[a constants or symbolic value](#value-phases) so the compiler can resolve
+[a constant or symbolic value](#value-phases) so the compiler can resolve
 whether the value can be used as a type. This also puts limits on how much
 operators can do different things for types. This is good for consistency, but
 is a significant restriction on Carbon's design.
@@ -655,12 +655,13 @@ address of an object in memory in Carbon.
 
 ### Expression categories
 
-Carbon expressions produce values or reference objects. Every expression has a
+A Carbon expression produces a value, references an object, or initializes an
+object. Every expression has a
 [category](<https://en.wikipedia.org/wiki/Value_(computer_science)#lrvalue>),
 similar to [C++](https://en.cppreference.com/w/cpp/language/value_category):
 
 -   [_Value expressions_](values.md#value-expressions) produce abstract,
-    read-only _values_ that cannot be modified or have its address taken.
+    read-only _values_ that cannot be modified or have their address taken.
 -   [_Reference expressions_](values.md#reference-expressions) refer to
     _objects_ with _storage_ where a value may be read or written and the
     object's address can be taken.
@@ -673,7 +674,7 @@ similar to [C++](https://en.cppreference.com/w/cpp/language/value_category):
 Expressions in one category can be converted to any other category when needed.
 The primitive conversion steps used are:
 
--   A _read_ converts a reference expression into a value expression.
+-   _Value binding_ converts a reference expression into a value expression.
 -   _Direct initialization_ converts a value expression into an initializing
     expression.
 -   _Copy initialization_ converts a reference expression into an initializing
@@ -798,11 +799,11 @@ not support
 [pointer arithmetic](<https://en.wikipedia.org/wiki/Pointer_(computer_programming)>);
 the only pointer [operations](#expressions) are:
 
--   Dereference: given a pointer `p`, `*p` gives the value `p` points to as an
+-   Dereference: given a pointer `p`, `*p` gives the value `p` points to as a
     [reference expression](#expression-categories). `p->m` is syntactic sugar
     for `(*p).m`.
--   Address-of: given an [reference expression](#expression-categories) `x`,
-    `&x` returns a pointer to `x`.
+-   Address-of: given a [reference expression](#expression-categories) `x`, `&x`
+    returns a pointer to `x`.
 
 There are no [null pointers](https://en.wikipedia.org/wiki/Null_pointer) in
 Carbon. To represent a pointer that may not refer to a valid object, use the
@@ -987,7 +988,7 @@ binding any name to it.
 Binding patterns default to _`let` bindings_. The `var` keyword is used to make
 it a _`var` binding_.
 
--   The result of a `let` binding is the name is bound to a
+-   A `let` binding binds a name to a value, so the name can be used as a
     [value expression](#expression-categories). This means the value cannot be
     modified, and its address generally cannot be taken.
 -   A `var` binding creates an object with dedicated storage, and so the name

docs/design/expressions/README.md

@@ -72,10 +72,13 @@ graph BT
     constType["const T"]
     click pointer-type "https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/expressions/type_operators.md"
 
-    pointerType["T*"]
+    pointerType>"T*"]
     click pointer-type "https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/expressions/type_operators.md"
 
-    pointer["*x<br>
+    %% FIXME: Need to switch unary operators from a left/right associativity to
+    %% a "repeated" marker, as we only have one direction for associativity and
+    %% that is wrong in this specific case.
+    pointer>"*x<br>
              &x<br>"]
     click pointer "https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/expressions/pointer.md"
 
@@ -142,6 +145,7 @@ graph BT
 
     constType --> top
     pointerType --> constType
+    as --> pointerType
 
     memberAccess --> top
     pointer --> memberAccess
@@ -150,9 +154,9 @@ graph BT
     unary --> negation & complement
     %% Use a longer arrow here to put `not` next to `and` and `or`.
     not -------> memberAccess
-    multiplication & modulo & as & bitwise_and & bitwise_or & bitwise_xor & shift --> unary
+    as & multiplication & modulo & bitwise_and & bitwise_or & bitwise_xor & shift --> unary
     addition --> multiplication
-    comparison --> modulo & addition & as & bitwise_and & bitwise_or & bitwise_xor & shift
+    comparison --> as & addition & modulo & bitwise_and & bitwise_or & bitwise_xor & shift
     logicalOperand --> comparison & not
     and & or --> logicalOperand
     logicalExpression --> and & or

docs/design/expressions/indexing.md

@@ -24,9 +24,9 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 Carbon supports indexing using the conventional `a[i]` subscript syntax. When
 `a` is a
-[_durable reference expression_](/docs/design/values.md#durable-reference-expressions),
+[durable reference expression](/docs/design/values.md#durable-reference-expressions),
 the result of subscripting is also a durable reference expression, but when `a`
-is a [_value expression_](/docs/design/values.md#value-expressions), the result
+is a [value expression](/docs/design/values.md#value-expressions), the result
 can be a durable reference expression or a value expression, depending on which
 interface the type implements:
 

docs/design/expressions/type_operators.md

@@ -42,17 +42,25 @@ The syntax of these operators tries to mimic the most common appearance of
 
 ### Precedence
 
-Because these are type operators, they don't have any precedence relationship
-with non-type operators. `const` binds more tightly than `*` and can appear
-unparenthesized in an operand, despite being both a unary type and having
-whitespace separating it. This allows the syntax of a pointer to a `const i32`
-to be `const i32*`, which is intended to be familiar to C++ developers. Forming
-a `const` pointer type requires parentheses: `const (i32*)`.
+Because these are type operators, they don't have many precedence relationship
+with non-type operators.
+
+-   `const` binds more tightly than `*` and can appear unparenthesized in an
+    operand, despite being both a unary type and having whitespace separating
+    it.
+    -   This allows the syntax of a pointer to a `const i32` to be `const i32*`,
+        which is intended to be familiar to C++ developers.
+    -   Forming a `const` pointer type requires parentheses: `const (i32*)`.
+-   All type operators bind more tightly than `as` so they can be used in its
+    type operand.
+    -   This also allows a desirable transitive precedence with `if`:
+        `if condition then T* else U*`.
 
 ## Alternatives considered
 
 -   [Alternative pointer syntaxes](/proposals/p2006.md#alternative-pointer-syntaxes)
 -   [Alternative syntaxes for locals](/proposals/p2006.md#alternative-syntaxes-for-locals)
+-   [Make `const` a postfix rather than prefix operator](/proposals/p2006.md#make-const-a-postfix-rather-than-prefix-operator)
 
 ## References
 

docs/design/generics/terminology.md

@@ -287,7 +287,7 @@ _Binding patterns_ associate a name with a type and a value. This is used to
 declare function parameters, in `let` and `var` declarations, as well as to
 declare [generic parameters](#generic-means-compile-time-parameterized). There
 are three kinds of binding patterns, corresponding to
-[the three value phases](/docs/design/README.md#value-categories-and-value-phases):
+[the three value phases](/docs/design/README.md#value-phases):
 
 -   A _runtime binding pattern_ binds to a dynamic value at runtime, and is
     written using a `:`, as in `x: i32`.