qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-11 20:40:21 -07:00
Code Releases Activity

doc/go_spec: tweak wording to avoid 'explicit assignment' misreading

Browse Source 
This text changed in CL 139099 to add "explicit" in front of "conversion".
But now "explicit conversion or assignment" reads like it might mean
"explicit [conversion or assignment]" when what is meant is
"[explicit conversion] or assignment". To make clear that explicit does
not apply to assignment, use "assignment or explicit conversion".

Change-Id: I8ff7a5b3ecd9f562793502fa6808242f22264f28
Reviewed-on: https://go-review.googlesource.com/c/149340
Reviewed-by: Robert Griesemer <gri@golang.org>
This commit is contained in:
Russ Cox 2018-11-13 10:23:01 -05:00
parent 94f7795d05
commit b7ba523355
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/go_spec.html
View File

@ -1,6 +1,6 @@
<!--{
"Title": "The Go Programming Language Specification",
"Subtitle": "Version of November 12, 2018",
"Subtitle": "Version of November 16, 2018",
"Path": "/ref/spec"
}-->
@ -1348,8 +1348,9 @@ 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 explicit
<a href="#Conversions">conversion</a> or <a href="#Assignments">assignment</a>.
A channel may be constrained only to send or only to receive by
<a href="#Assignments">assignment</a> or
explicit <a href="#Conversions">conversion</a>.
</p>
<pre>
@ -3624,7 +3625,7 @@ For signed integers, the operations <code>+</code>,
<code>-</code>, <code>*</code>, <code>/</code>, and <code>&lt;&lt;</code> may legally
overflow and the resulting value exists and is deterministically defined
by the signed integer representation, the operation, and its operands.
Overflow does not cause a <a href="#Run_time_panics">run-time panic</a>.
Overflow does not cause a <a href="#Run_time_panics">run-time panic</a>.
A compiler may not optimize code under the assumption that overflow does
not occur. For instance, it may not assume that <code>x &lt; x + 1</code> is always true.
</p>