spec: distinguish between explicit and implicit conversions (clarification)

The spec used the term "conversion" somewhat indiscriminately for
explicit conversions that appear literally in the source, and implicit
conversions that are implied by the context of an expression.
Be clearer about it by defining the terms.

Also, state that integer to string conversions of the form string(x)
are never implicit. This clarifies situations where implicit conversions
might require an integer to change to a string (but don't and never have
done so). See line 3948.

Fixes #26313.

Change-Id: I8939466df6b5950933ae7c987662ef9f88827fda
Reviewed-on: https://go-review.googlesource.com/c/139099
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

1 files changed, 23 insertions, 16 deletions

diff --git a/doc/go_spec.html b/doc/go_spec.html
index 32336e86f8..6c7f2aa902 100644
--- a/doc/go_spec.html
+++ b/doc/go_spec.html
@@ -1,6 +1,6 @@
 <!--{
 	"Title": "The Go Programming Language Specification",
-	"Subtitle": "Version of September 24, 2018",
+	"Subtitle": "Version of October 8, 2018",
 	"Path": "/ref/spec"
 }-->
 
@@ -811,7 +811,7 @@ To avoid portability issues all numeric types are <a href="#Type_definitions">de
 types</a> and thus distinct except
 <code>byte</code>, which is an <a href="#Alias_declarations">alias</a> for <code>uint8</code>, and
 <code>rune</code>, which is an alias for <code>int32</code>.
-Conversions
+Explicit conversions
 are required when different numeric types are mixed in an expression
 or assignment. For instance, <code>int32</code> and <code>int</code>
 are not the same type even though they may have the same size on a
@@ -1348,7 +1348,7 @@ ChannelType = ( "chan" | "chan" "&lt;-" | "&lt;-" "chan" ) ElementType .
 The optional <code>&lt;-</code> operator specifies the channel <i>direction</i>,
 <i>send</i> or <i>receive</i>. If no direction is given, the channel is
 <i>bidirectional</i>.
-A channel may be constrained only to send or only to receive by
+A channel may be constrained only to send or only to receive by explicit
 <a href="#Conversions">conversion</a> or <a href="#Assignments">assignment</a>.
 </p>
 
@@ -2069,9 +2069,9 @@ Otherwise, each variable is initialized to its <a href="#The_zero_value">zero va
 If a type is present, each variable is given that type.
 Otherwise, each variable is given the type of the corresponding
 initialization value in the assignment.
-If that value is an untyped constant, it is first
+If that value is an untyped constant, it is first implicitly
 <a href="#Conversions">converted</a> to its <a href="#Constants">default type</a>;
-if it is an untyped boolean value, it is first converted to type <code>bool</code>.
+if it is an untyped boolean value, it is first implicitly converted to type <code>bool</code>.
 The predeclared value <code>nil</code> cannot be used to initialize a variable
 with no explicit type.
 </p>
@@ -3433,7 +3433,7 @@ For operations involving constants only, see the section on
 
 <p>
 Except for shift operations, if one operand is an untyped <a href="#Constants">constant</a>
-and the other operand is not, the constant is <a href="#Conversions">converted</a>
+and the other operand is not, the constant is implicitly <a href="#Conversions">converted</a>
 to the type of the other operand.
 </p>
 
@@ -3442,7 +3442,7 @@ The right operand in a shift expression must have unsigned integer type
 or be an untyped constant <a href="#Representability">representable</a> by a
 value of type <code>uint</code>.
 If the left operand of a non-constant shift expression is an untyped constant,
-it is first converted to the type it would assume if the shift expression were
+it is first implicitly converted to the type it would assume if the shift expression were
 replaced by its left operand alone.
 </p>
 
@@ -3645,7 +3645,7 @@ occurs is implementation-specific.
 An implementation may combine multiple floating-point operations into a single
 fused operation, possibly across statements, and produce a result that differs
 from the value obtained by executing and rounding the instructions individually.
-A floating-point type <a href="#Conversions">conversion</a> explicitly rounds to
+An explicit floating-point type <a href="#Conversions">conversion</a> rounds to
 the precision of the target type, preventing fusion that would discard that rounding.
 </p>
 
@@ -3907,7 +3907,14 @@ channel is closed and empty.
 <h3 id="Conversions">Conversions</h3>
 
 <p>
-Conversions are expressions of the form <code>T(x)</code>
+A conversion changes the <a href="#Types">type</a> of an expression
+to the type specified by the conversion.
+A conversion may appear literally in the source, or it may be <i>implied</i>
+by the context in which an expression appears.
+</p>
+
+<p>
+An <i>explicit</i> conversion is an expression of the form <code>T(x)</code>
 where <code>T</code> is a type and <code>x</code> is an expression
 that can be converted to type <code>T</code>.
 </p>
@@ -3938,7 +3945,7 @@ func() int(x)    // x is converted to func() int (unambiguous)
 A <a href="#Constants">constant</a> value <code>x</code> can be converted to
 type <code>T</code> if <code>x</code> is <a href="#Representability">representable</a>
 by a value of <code>T</code>.
-As a special case, an integer constant <code>x</code> can be converted to a
+As a special case, an integer constant <code>x</code> can be explicitly converted to a
 <a href="#String_types">string type</a> using the
 <a href="#Conversions_to_and_from_a_string_type">same rule</a>
 as for non-constant <code>x</code>.
@@ -4672,13 +4679,13 @@ to the type of the operand to which it is assigned, with the following special c
 <li>
 	If an untyped constant
 	is assigned to a variable of interface type or the blank identifier,
-	the constant is first <a href="#Conversions">converted</a> to its
+	the constant is first implicitly <a href="#Conversions">converted</a> to its
 	 <a href="#Constants">default type</a>.
 </li>
 
 <li>
 	If an untyped boolean value is assigned to a variable of interface type or
-	the blank identifier, it is first converted to type <code>bool</code>.
+	the blank identifier, it is first implicitly converted to type <code>bool</code>.
 </li>
 </ol>
 
@@ -4764,14 +4771,14 @@ ExprSwitchCase = "case" ExpressionList | "default" .
 </pre>
 
 <p>
-If the switch expression evaluates to an untyped constant, it is first
+If the switch expression evaluates to an untyped constant, it is first implicitly
 <a href="#Conversions">converted</a> to its <a href="#Constants">default type</a>;
-if it is an untyped boolean value, it is first converted to type <code>bool</code>.
+if it is an untyped boolean value, it is first implicitly converted to type <code>bool</code>.
 The predeclared untyped value <code>nil</code> cannot be used as a switch expression.
 </p>
 
 <p>
-If a case expression is untyped, it is first <a href="#Conversions">converted</a>
+If a case expression is untyped, it is first implicitly <a href="#Conversions">converted</a>
 to the type of the switch expression.
 For each (possibly converted) case expression <code>x</code> and the value <code>t</code>
 of the switch expression, <code>x == t</code> must be a valid <a href="#Comparison_operators">comparison</a>.
@@ -5881,7 +5888,7 @@ floating-point type and the return type is the complex type
 with the corresponding floating-point constituents:
 <code>complex64</code> for <code>float32</code> arguments, and
 <code>complex128</code> for <code>float64</code> arguments.
-If one of the arguments evaluates to an untyped constant, it is first
+If one of the arguments evaluates to an untyped constant, it is first implicitly
 <a href="#Conversions">converted</a> to the type of the other argument.
 If both arguments evaluate to untyped constants, they must be non-complex
 numbers or their imaginary parts must be zero, and the return value of