Commit 48ba6fe5 authored by Andrew Gerrand's avatar Andrew Gerrand

doc: move spec and memory model back to /ref/

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/14364043
parent 4cc71e33
...@@ -154,7 +154,7 @@ function to return <code>*Page</code> and <code>error</code>. ...@@ -154,7 +154,7 @@ function to return <code>*Page</code> and <code>error</code>.
Callers of this function can now check the second parameter; if it is Callers of this function can now check the second parameter; if it is
<code>nil</code> then it has successfully loaded a Page. If not, it will be an <code>nil</code> then it has successfully loaded a Page. If not, it will be an
<code>error</code> that can be handled by the caller (see the <code>error</code> that can be handled by the caller (see the
<a href="/doc/spec#Errors">language specification</a> for details). <a href="/ref/spec#Errors">language specification</a> for details).
</p> </p>
<p> <p>
...@@ -616,7 +616,7 @@ Let's put a call to <code>getTitle</code> in each of the handlers: ...@@ -616,7 +616,7 @@ Let's put a call to <code>getTitle</code> in each of the handlers:
Catching the error condition in each handler introduces a lot of repeated code. Catching the error condition in each handler introduces a lot of repeated code.
What if we could wrap each of the handlers in a function that does this What if we could wrap each of the handlers in a function that does this
validation and error checking? Go's validation and error checking? Go's
<a href="/doc/spec#Function_literals">function <a href="/ref/spec#Function_literals">function
literals</a> provide a powerful means of abstracting functionality literals</a> provide a powerful means of abstracting functionality
that can help us here. that can help us here.
</p> </p>
......
...@@ -85,12 +85,12 @@ The documentation for the Go standard library. ...@@ -85,12 +85,12 @@ The documentation for the Go standard library.
The documentation for the Go tools. The documentation for the Go tools.
</p> </p>
<h3 id="spec"><a href="/doc/spec">Language Specification</a></h3> <h3 id="spec"><a href="/ref/spec">Language Specification</a></h3>
<p> <p>
The official Go Language specification. The official Go Language specification.
</p> </p>
<h3 id="go_mem"><a href="/doc/mem">The Go Memory Model</a></h3> <h3 id="go_mem"><a href="/ref/mem">The Go Memory Model</a></h3>
<p> <p>
A document that specifies the conditions under which reads of a variable in A document that specifies the conditions under which reads of a variable in
one goroutine can be guaranteed to observe values produced by writes to the one goroutine can be guaranteed to observe values produced by writes to the
......
...@@ -27,7 +27,7 @@ will be easy for other Go programmers to understand. ...@@ -27,7 +27,7 @@ will be easy for other Go programmers to understand.
<p> <p>
This document gives tips for writing clear, idiomatic Go code. This document gives tips for writing clear, idiomatic Go code.
It augments the <a href="/doc/spec">language specification</a>, It augments the <a href="/ref/spec">language specification</a>,
the <a href="http://tour.golang.org/">Tour of Go</a>, the <a href="http://tour.golang.org/">Tour of Go</a>,
and <a href="/doc/code.html">How to Write Go Code</a>, and <a href="/doc/code.html">How to Write Go Code</a>,
all of which you all of which you
...@@ -709,7 +709,7 @@ Erroneous encodings consume one byte and produce the ...@@ -709,7 +709,7 @@ Erroneous encodings consume one byte and produce the
replacement rune U+FFFD. replacement rune U+FFFD.
(The name (with associated builtin type) <code>rune</code> is Go terminology for a (The name (with associated builtin type) <code>rune</code> is Go terminology for a
single Unicode code point. single Unicode code point.
See <a href="http://golang.org/doc/spec#Rune_literals">the language specification</a> See <a href="http://golang.org/ref/spec#Rune_literals">the language specification</a>
for details.) for details.)
The loop The loop
</p> </p>
...@@ -2969,7 +2969,7 @@ func Serve(queue chan *Request) { ...@@ -2969,7 +2969,7 @@ func Serve(queue chan *Request) {
<p> <p>
Because data synchronization occurs on a receive from a channel Because data synchronization occurs on a receive from a channel
(that is, the send "happens before" the receive; see (that is, the send "happens before" the receive; see
<a href="/doc/mem">The Go Memory Model</a>), <a href="/ref/mem">The Go Memory Model</a>),
acquisition of the semaphore must be on a channel receive, not a send. acquisition of the semaphore must be on a channel receive, not a send.
</p> </p>
......
...@@ -81,7 +81,7 @@ See the <a href="#unicode">Unicode</a> section for more information. ...@@ -81,7 +81,7 @@ See the <a href="#unicode">Unicode</a> section for more information.
<p> <p>
Go 1.1 now implements Go 1.1 now implements
<a href="/doc/spec#Method_values">method values</a>, <a href="/ref/spec#Method_values">method values</a>,
which are functions that have been bound to a specific receiver value. which are functions that have been bound to a specific receiver value.
For instance, given a For instance, given a
<a href="/pkg/bufio/#Writer"><code>Writer</code></a> <a href="/pkg/bufio/#Writer"><code>Writer</code></a>
...@@ -129,7 +129,7 @@ only an infinite "for" loop. ...@@ -129,7 +129,7 @@ only an infinite "for" loop.
<p> <p>
In Go 1.1, the rule about final "return" statements is more permissive. In Go 1.1, the rule about final "return" statements is more permissive.
It introduces the concept of a It introduces the concept of a
<a href="/doc/spec/#Terminating_statements"><em>terminating statement</em></a>, <a href="/ref/spec/#Terminating_statements"><em>terminating statement</em></a>,
a statement that is guaranteed to be the last one a function executes. a statement that is guaranteed to be the last one a function executes.
Examples include Examples include
"for" loops with no condition and "if-else" "for" loops with no condition and "if-else"
...@@ -191,7 +191,7 @@ more than 2 billion elements on 64-bit platforms. ...@@ -191,7 +191,7 @@ more than 2 billion elements on 64-bit platforms.
<em>Updating</em>: <em>Updating</em>:
Most programs will be unaffected by this change. Most programs will be unaffected by this change.
Because Go does not allow implicit conversions between distinct Because Go does not allow implicit conversions between distinct
<a href="/doc/spec/#Numeric_types">numeric types</a>, <a href="/ref/spec/#Numeric_types">numeric types</a>,
no programs will stop compiling due to this change. no programs will stop compiling due to this change.
However, programs that contain implicit assumptions However, programs that contain implicit assumptions
that <code>int</code> is only 32 bits may change behavior. that <code>int</code> is only 32 bits may change behavior.
......
...@@ -68,7 +68,7 @@ Go became a public open source project on November 10, 2009. ...@@ -68,7 +68,7 @@ Go became a public open source project on November 10, 2009.
After a couple of years of very active design and development, stability was called for and After a couple of years of very active design and development, stability was called for and
Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a> Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
on March 28, 2012. on March 28, 2012.
Go 1, which includes a <a href="/doc/spec">language specification</a>, Go 1, which includes a <a href="/ref/spec">language specification</a>,
<a href="/pkg/">standard libraries</a>, <a href="/pkg/">standard libraries</a>,
and <a href="/cmd/go/">custom tools</a>, and <a href="/cmd/go/">custom tools</a>,
provides a stable foundation for creating reliable products, projects, and publications. provides a stable foundation for creating reliable products, projects, and publications.
...@@ -1278,7 +1278,7 @@ What operations are atomic? What about mutexes?</h3> ...@@ -1278,7 +1278,7 @@ What operations are atomic? What about mutexes?</h3>
<p> <p>
We haven't fully defined it all yet, but some details about atomicity are We haven't fully defined it all yet, but some details about atomicity are
available in the <a href="/doc/mem">Go Memory Model specification</a>. available in the <a href="/ref/mem">Go Memory Model specification</a>.
</p> </p>
<p> <p>
...@@ -1334,7 +1334,7 @@ will experience performance degradation when using ...@@ -1334,7 +1334,7 @@ will experience performance degradation when using
multiple OS threads. multiple OS threads.
This is because sending data between threads involves switching This is because sending data between threads involves switching
contexts, which has significant cost. contexts, which has significant cost.
For instance, the <a href="/doc/spec#An_example_package">prime sieve example</a> For instance, the <a href="/ref/spec#An_example_package">prime sieve example</a>
from the Go specification has no significant parallelism although it launches many from the Go specification has no significant parallelism although it launches many
goroutines; increasing <code>GOMAXPROCS</code> is more likely to slow it down than goroutines; increasing <code>GOMAXPROCS</code> is more likely to slow it down than
to speed it up. to speed it up.
...@@ -1357,7 +1357,7 @@ is not Parallelism</a>. ...@@ -1357,7 +1357,7 @@ is not Parallelism</a>.
Why do T and *T have different method sets?</h3> Why do T and *T have different method sets?</h3>
<p> <p>
From the <a href="/doc/spec#Types">Go Spec</a>: From the <a href="/ref/spec#Types">Go Spec</a>:
</p> </p>
<blockquote> <blockquote>
......
<!--{ <!--{
"Title": "The Go Memory Model", "Title": "The Go Memory Model",
"Subtitle": "Version of March 6, 2012", "Subtitle": "Version of March 6, 2012",
"Path": "/doc/mem" "Path": "/ref/mem"
}--> }-->
<style> <style>
......
<!--{ <!--{
"Title": "The Go Programming Language Specification", "Title": "The Go Programming Language Specification",
"Subtitle": "Version of Oct 3, 2013", "Subtitle": "Version of Oct 3, 2013",
"Path": "/doc/spec" "Path": "/ref/spec"
}--> }-->
<!-- <!--
......
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