Commit c50074e5 authored by Stefan Nilsson's avatar Stefan Nilsson Committed by Robert Griesemer

doc: add a bunch of missing <p> tags

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/5707065
parent 6652b0b8
...@@ -323,7 +323,7 @@ foo_amd64.go ...@@ -323,7 +323,7 @@ foo_amd64.go
foo_arm.go foo_arm.go
</pre> </pre>
describes a package that builds on <p>describes a package that builds on
different architectures by parameterizing the file name with different architectures by parameterizing the file name with
<code>$GOARCH</code>.</p> <code>$GOARCH</code>.</p>
......
...@@ -1617,40 +1617,49 @@ Now we have the missing piece we needed to explain the design of ...@@ -1617,40 +1617,49 @@ Now we have the missing piece we needed to explain the design of
the <code>append</code> built-in function. The signature of <code>append</code> the <code>append</code> built-in function. The signature of <code>append</code>
is different from our custom <code>Append</code> function above. is different from our custom <code>Append</code> function above.
Schematically, it's like this: Schematically, it's like this:
</p>
<pre> <pre>
func append(slice []<i>T</i>, elements...T) []<i>T</i> func append(slice []<i>T</i>, elements...T) []<i>T</i>
</pre> </pre>
<p>
where <i>T</i> is a placeholder for any given type. You can't where <i>T</i> is a placeholder for any given type. You can't
actually write a function in Go where the type <code>T</code> actually write a function in Go where the type <code>T</code>
is determined by the caller. is determined by the caller.
That's why <code>append</code> is built in: it needs support from the That's why <code>append</code> is built in: it needs support from the
compiler. compiler.
</p>
<p> <p>
What <code>append</code> does is append the elements to the end of What <code>append</code> does is append the elements to the end of
the slice and return the result. The result needs to be returned the slice and return the result. The result needs to be returned
because, as with our hand-written <code>Append</code>, the underlying because, as with our hand-written <code>Append</code>, the underlying
array may change. This simple example array may change. This simple example
</p>
<pre> <pre>
x := []int{1,2,3} x := []int{1,2,3}
x = append(x, 4, 5, 6) x = append(x, 4, 5, 6)
fmt.Println(x) fmt.Println(x)
</pre> </pre>
<p>
prints <code>[1 2 3 4 5 6]</code>. So <code>append</code> works a prints <code>[1 2 3 4 5 6]</code>. So <code>append</code> works a
little like <code>Printf</code>, collecting an arbitrary number of little like <code>Printf</code>, collecting an arbitrary number of
arguments. arguments.
</p>
<p> <p>
But what if we wanted to do what our <code>Append</code> does and But what if we wanted to do what our <code>Append</code> does and
append a slice to a slice? Easy: use <code>...</code> at the call append a slice to a slice? Easy: use <code>...</code> at the call
site, just as we did in the call to <code>Output</code> above. This site, just as we did in the call to <code>Output</code> above. This
snippet produces identical output to the one above. snippet produces identical output to the one above.
</p>
<pre> <pre>
x := []int{1,2,3} x := []int{1,2,3}
y := []int{4,5,6} y := []int{4,5,6}
x = append(x, y...) x = append(x, y...)
fmt.Println(x) fmt.Println(x)
</pre> </pre>
<p>
Without that <code>...</code>, it wouldn't compile because the types Without that <code>...</code>, it wouldn't compile because the types
would be wrong; <code>y</code> is not of type <code>int</code>. would be wrong; <code>y</code> is not of type <code>int</code>.
</p>
<h2 id="initialization">Initialization</h2> <h2 id="initialization">Initialization</h2>
......
...@@ -1613,40 +1613,49 @@ Now we have the missing piece we needed to explain the design of ...@@ -1613,40 +1613,49 @@ Now we have the missing piece we needed to explain the design of
the <code>append</code> built-in function. The signature of <code>append</code> the <code>append</code> built-in function. The signature of <code>append</code>
is different from our custom <code>Append</code> function above. is different from our custom <code>Append</code> function above.
Schematically, it's like this: Schematically, it's like this:
</p>
<pre> <pre>
func append(slice []<i>T</i>, elements...T) []<i>T</i> func append(slice []<i>T</i>, elements...T) []<i>T</i>
</pre> </pre>
<p>
where <i>T</i> is a placeholder for any given type. You can't where <i>T</i> is a placeholder for any given type. You can't
actually write a function in Go where the type <code>T</code> actually write a function in Go where the type <code>T</code>
is determined by the caller. is determined by the caller.
That's why <code>append</code> is built in: it needs support from the That's why <code>append</code> is built in: it needs support from the
compiler. compiler.
</p>
<p> <p>
What <code>append</code> does is append the elements to the end of What <code>append</code> does is append the elements to the end of
the slice and return the result. The result needs to be returned the slice and return the result. The result needs to be returned
because, as with our hand-written <code>Append</code>, the underlying because, as with our hand-written <code>Append</code>, the underlying
array may change. This simple example array may change. This simple example
</p>
<pre> <pre>
x := []int{1,2,3} x := []int{1,2,3}
x = append(x, 4, 5, 6) x = append(x, 4, 5, 6)
fmt.Println(x) fmt.Println(x)
</pre> </pre>
<p>
prints <code>[1 2 3 4 5 6]</code>. So <code>append</code> works a prints <code>[1 2 3 4 5 6]</code>. So <code>append</code> works a
little like <code>Printf</code>, collecting an arbitrary number of little like <code>Printf</code>, collecting an arbitrary number of
arguments. arguments.
</p>
<p> <p>
But what if we wanted to do what our <code>Append</code> does and But what if we wanted to do what our <code>Append</code> does and
append a slice to a slice? Easy: use <code>...</code> at the call append a slice to a slice? Easy: use <code>...</code> at the call
site, just as we did in the call to <code>Output</code> above. This site, just as we did in the call to <code>Output</code> above. This
snippet produces identical output to the one above. snippet produces identical output to the one above.
</p>
<pre> <pre>
x := []int{1,2,3} x := []int{1,2,3}
y := []int{4,5,6} y := []int{4,5,6}
x = append(x, y...) x = append(x, y...)
fmt.Println(x) fmt.Println(x)
</pre> </pre>
<p>
Without that <code>...</code>, it wouldn't compile because the types Without that <code>...</code>, it wouldn't compile because the types
would be wrong; <code>y</code> is not of type <code>int</code>. would be wrong; <code>y</code> is not of type <code>int</code>.
</p>
<h2 id="initialization">Initialization</h2> <h2 id="initialization">Initialization</h2>
......
...@@ -1524,7 +1524,9 @@ declaration should present the same order as <code>:=</code> so ...@@ -1524,7 +1524,9 @@ declaration should present the same order as <code>:=</code> so
<pre> <pre>
var a uint64 = 1 var a uint64 = 1
</pre> </pre>
<p>
has the same effect as has the same effect as
</p>
<pre> <pre>
a := uint64(1) a := uint64(1)
</pre> </pre>
......
...@@ -696,10 +696,11 @@ using a receiver of that type. ...@@ -696,10 +696,11 @@ using a receiver of that type.
<h3 id="Boolean_types">Boolean types</h3> <h3 id="Boolean_types">Boolean types</h3>
<p>
A <i>boolean type</i> represents the set of Boolean truth values A <i>boolean type</i> represents the set of Boolean truth values
denoted by the predeclared constants <code>true</code> denoted by the predeclared constants <code>true</code>
and <code>false</code>. The predeclared boolean type is <code>bool</code>. and <code>false</code>. The predeclared boolean type is <code>bool</code>.
</p>
<h3 id="Numeric_types">Numeric types</h3> <h3 id="Numeric_types">Numeric types</h3>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment