go/doc/go1.html

<!-- Go 1 Release Notes -->
<!--
  DO NOT EDIT: created by
    tmpltohtml go1.tmpl
-->


<h2 id="introduction">Introduction to Go 1</h2>

<p>
For a full explanation of the motivation and design of Go 1, see XXX.
Here follows a summary.
</p>

<p>
Go 1 is intended to be a stable language and core library set that
will form a reliable foundation for people and organizations that
want to make a long-term commitment to developing in the Go programming
language. Go will continue to develop, but in a way that guarantees
code written to the Go 1 specification will continue to work. For
instance, Go 1 will be a supported platform on Google App Engine
for the next few years. Incompatible changes to the environment,
should they arise, will be done in a distinct version.
</p>

<p>
This document describes the changes in the language and libraries
in Go 1, relative to the previous release, r60 (at the time of
writing, tagged as r60.3). It also explains how to update code at
r60 to compile and run under Go 1. Finally, it outlines the new
<code>go</code> command for building Go programs and the new binary
release process being introduced. Most of these topics have more
thorough presentations elsewhere; such documents are linked below.
</p>

<h2 id="language">Changes to the language</h2>

<h3 id="append">Append</h3>

<p>
The <code>append</code> built-in function is variadic, so one can
append to a byte slice using the <code>...</code> syntax in the
call.
</p>

<pre><!--{{code "progs/go1.go" `/greeting := ..byte/` `/append.*hello/`}}
-->    greeting := []byte{}
    greeting = append(greeting, []byte(&#34;hello &#34;)...)
</pre>

<p>
By analogy with the similar property of <code>copy</code>, Go 1
permits a string to be appended (byte-wise) directly to a byte
slice; the conversion is no longer necessary:
</p>

<pre><!--{{code "progs/go1.go" `/append.*world/`}}
-->    greeting = append(greeting, &#34;world&#34;...)
</pre>

<p>
<em>Updating</em>:
This is a new feature, so existing code needs no changes.
</p>

<h3 id="close">Close</h3>

<p>
The <code>close</code> built-in function lets a sender tell a receiver
that no more data will be transmitted on the channel.  In Go 1 the
type system enforces the directionality when possible: it is illegal
to call <code>close</code> on a receive-only channel:
</p>

<pre>
    var c chan int
    var csend chan<- int = c
    var crecv <-chan int = c
    close(c)     // legal
    close(csend) // legal
    close(crecv) // illegal
</pre>

<p>
<em>Updating</em>:
Existing code that attempts to close a receive-only channel was
erroneous even before Go 1 and should be fixed.  The compiler will
now reject such code.
</p>

<h3 id="literals">Composite literals</h3>

<p>
In Go 1, a composite literal of array, slice, or map type can elide the
type specification for the elements' initializers if they are of pointer type.
All four of the initializations in this example are legal; the last one was illegal before Go 1.
</p>

<pre><!--{{code "progs/go1.go" `/type Date struct/` `/STOP/`}}
-->    type Date struct {
        month string
        day   int
    }
    // Struct values, fully qualified; always legal.
    holiday1 := []Date{
        Date{&#34;Feb&#34;, 14},
        Date{&#34;Nov&#34;, 11},
        Date{&#34;Dec&#34;, 25},
    }
    // Struct values, type name elided; always legal.
    holiday2 := []Date{
        {&#34;Feb&#34;, 14},
        {&#34;Nov&#34;, 11},
        {&#34;Dec&#34;, 25},
    }
    // Pointers, fully qualified, always legal.
    holiday3 := []*Date{
        &amp;Date{&#34;Feb&#34;, 14},
        &amp;Date{&#34;Nov&#34;, 11},
        &amp;Date{&#34;Dec&#34;, 25},
    }
    // Pointers, type name elided; legal in Go 1.
    holiday4 := []*Date{
        {&#34;Feb&#34;, 14},
        {&#34;Nov&#34;, 11},
        {&#34;Dec&#34;, 25},
    }
</pre>

<p>
<em>Updating</em>:
This change has no effect on existing code, but the command
<code>gofmt</code> <code>-s</code> applied to existing source
will, among other things, elide explicit element types wherever permitted.
</p>


<h3 id="init">Goroutines during init</h3>

<p>
Go 1 allows goroutines to be created and run during initialization.
(They used to be created but were not run until after initialization
completed.) Code that uses goroutines can now be called from
<code>init</code> routines and global initialization expressions
without introducing a deadlock.
</p>

<pre><!--{{code "progs/go1.go" `/PackageGlobal/` `/^}/`}}
-->var PackageGlobal int

func init() {
    c := make(chan int)
    go initializationFunction(c)
    PackageGlobal = &lt;-c
}
</pre>

<p>
<em>Updating</em>:
This is a new feature, so existing code needs no changes,
although it's possible that code that depends on goroutines not starting before <code>main</code> will break.
There was no such code in the standard repository.
</p>

<h3 id="rune">The rune type</h3>

<p>
Go 1 introduces a new basic type, <code>rune</code>, to be used to represent
individual Unicode code points.
It is an alias for <code>int32</code>, analogous to <code>byte</code>
as an alias for <code>uint8</code>.
</p>

<p>
Character literals such as <code>'a'</code>, <code>'語'</code>, and <code>'\u0345'</code>
now have default type <code>rune</code>,
analogous to <code>1.0</code> having default type <code>float64</code>.
A variable initialized to a character constant will therefore
have type <code>rune</code> unless otherwise specified.
</p>

<p>
Libraries have been updated to use <code>rune</code> rather than <code>int</code>
when appropriate. For instance, the functions <code>unicode.ToLower</code> and
relatives now take and return a <code>rune</code>.
</p>

<pre><!--{{code "progs/go1.go" `/STARTRUNE/` `/ENDRUNE/`}}
-->    delta := &#39;δ&#39; // delta has type rune.
    var DELTA rune
    DELTA = unicode.ToUpper(delta)
    epsilon := unicode.ToLower(DELTA + 1)
    if epsilon != &#39;δ&#39;+1 {
        log.Fatal(&#34;inconsistent casing for Greek&#34;)
    }
</pre>

<p>
<em>Updating</em>:
Most source code will be unaffected by this because the type inference from
<code>:=</code> initializers introduces the new type silently, and it propagates
from there.
Some code may get type errors that a trivial conversion will resolve.
</p>

<h3 id="error">The error type</h3>

<p>
Go 1 introduces a new built-in type, <code>error</code>, which has the following definition:
</p>

<pre>
    type error interface {
        Error() string
    }
</pre>

<p>
Since the consequences of this type are all in the package library,
it is discussed <a href="errors">below</a>.
</p>

<h3 id="delete">Deleting from maps</h3>

<p>
The original syntax for deleting an element in a map was:
</p>

<pre>
    m[k] = ignored, false
</pre>

<p>
In Go 1, that syntax has gone; instead there is a new built-in
function, <code>delete</code>.  The call
</p>

<pre><!--{{code "progs/go1.go" `/delete\(m, k\)/`}}
-->    delete(m, k)
</pre>

<p>
will delete the map entry retrieved by the expression <code>m[k]</code>.
There is no return value. Deleting a non-existent entry is a no-op.
</p>

<p>
<em>Updating</em>:
Gofix will convert expressions of the form <code>m[k] = ignored,
false</code> into <code>delete(m, k)</code> when it is clear that
the ignored value can be safely discarded from the program and
<code>false</code> refers to the predefined boolean constant.  Gofix
will flag other uses of the syntax for inspection by the programmer.
</p>

<h3 id="iteration">Iterating in maps</h3>

<p>
In Go 1, the order in which elements are visited when iterating
over a map using a <code>for</code> <code>range</code> statement
is defined to be unpredictable, even if the same loop is run multiple
times with the same map.
Code should not assume that the elements are visited in any particular order.
</p>

<pre><!--{{code "progs/go1.go" `/Sunday/` `/^	}/`}}
-->    m := map[string]int{&#34;Sunday&#34;: 0, &#34;Monday&#34;: 1}
    for name, value := range m {
        // This loop should not assume Sunday will be visited first.
        f(name, value)
    }
</pre>

<p>
<em>Updating</em>:
This is one change where tools cannot help.  Most existing code
will be unaffected, but some programs may break or misbehave; we
recommend manual checking of all range statements over maps to
verify they do not depend on iteration order. There were a few such
examples in the standard repository; they have been fixed.
Note that it was already incorrect to depend on the iteration order, which
was unspecified. This change codifies the unpredictability.
</p>

<h3 id="multiple_assignment">Multiple assignment</h3>

<p>
Go 1 fully specifies the evaluation order in multiple assignment
statements. In particular, if the left-hand side of the assignment
statement contains expressions that require evaluation, such as
function calls or array indexing operations, these will all be done
using the usual left-to-right rule before any variables are assigned
their value.  Once everything is evaluated, the actual assignments
proceed in left-to-right order.
</p>

<p>
These examples illustrate the behavior.
</p>

<pre><!--{{code "progs/go1.go" `/sa :=/` `/then sc.0. = 2/`}}
-->    sa := []int{1, 2, 3}
    i := 0
    i, sa[i] = 1, 2 // sets i = 1, sa[0] = 2

    sb := []int{1, 2, 3}
    j := 0
    sb[j], j = 2, 1 // sets sb[0] = 2, j = 1

    sc := []int{1, 2, 3}
    sc[0], sc[0] = 1, 2 // sets sc[0] = 1, then sc[0] = 2 (so sc[0] = 2 at end)
</pre>

<p>
<em>Updating</em>:
This is one change where tools cannot help, but breakage is unlikely.
No code in the standard repository was broken by this change, and code
that depended on the previous unspecified behavior was already incorrect.
</p>

<h3 id="shadowing">Returns and shadowed variables</h3>

<p>
A shadowed variable is one that has the same name as another variable in an inner scope.
In functions with named return values,
the Go 1 compilers disallow return statements without arguments if any of the named return values is shadowed at the point of the return statement.
(It isn't part of the specification, because this is one area we are still exploring;
the situation is analogous to the compilers rejecting functions that do not end with an explicit return statement.)
</p>

<p>
This function implicitly returns a shadowed return value and will be rejected by the compiler:
</p>

<pre>
    func Bug() (i, j, k int) {
        for i = 0; i < 5; i++ {
            for j := 0; j < 5; j++ { // Redeclares j.
                k += i*j
                if k > 100 {
                    return // Rejected: j is shadowed here.
                }
            }
        }
        return // OK: j is not shadowed here.
    }
</pre>

<p>
<em>Updating</em>:
Code that shadows return values in this way will be rejected by the compiler and will need to be fixed by hand.
The few cases that arose in the standard repository were mostly bugs.
</p>

<h3 id="unexported">Copying structs with unexported fields</h3>

<p>
Go 1 relaxes the rules about accessing structs with unexported (lower-case) fields,
permitting a client package to assign (and therefore copy) such a struct.
Of course, the client package still cannot access such fields individually.
</p>

<p>
As an example, if package <code>p</code> includes the definitions,
</p>

<pre>
    type Struct struct {
        Public int
        secret int
    }
    func NewStruct(a int) Struct {  // Note: not a pointer.
        return Struct{a, f(a)}
    }
    func (s Struct) String() string {
        return fmt.Sprintf("{%d (secret %d)}", s.Public, s.secret)
    }
</pre>

<p>
a package that imports <code>p</code> can assign and copy values of type
<code>p.Struct</code> at will.
Behind the scenes the unexported fields will be assigned and copied just
as if they were exported,
but the client code will never be aware of them. The code
</p>

<pre>
    import "p"

    myStruct := p.NewStruct(23)
    copyOfMyStruct := myStruct
    fmt.Println(myStruct, copyOfMyStruct)
</pre>

<p>
will show that the secret field of the struct has been copied to the new value.
</p>

<p>
<em>Updating</em>:
This is a new feature, so existing code needs no changes.
</p>

<h3 id="equality">Equality of structs and arrays</h3>

<p>
Go 1 defines equality and inequality (<code>==</code> and
<code>!=</code>) for struct and array values, respectively, provided
the elements of the data structures can themselves be compared.
That is, if equality is defined for all the fields of a struct (or
an array element), then it is defined for the struct (or array).
</p>

<p>
As a result, structs and arrays can now be used as map keys:
</p>

<pre><!--{{code "progs/go1.go" `/type Day struct/` `/Printf/`}}
-->    //    type Day struct {
    //        long string
    //        short string
    //    }
    //    Christmas := Day{&#34;Christmas&#34;, &#34;XMas&#34;}
    //    Thanksgiving := Day{&#34;Thanksgiving&#34;, &#34;Turkey&#34;}
    //    holiday := map[Day]bool {
    //        Christmas: true,
    //        Thanksgiving: true,
    //    }
    //    fmt.Printf(&#34;Christmas is a holiday: %t\n&#34;, holiday[Christmas])
</pre>

<p>
Note that equality is still undefined for slices, for which the
calculation is in general infeasible.  Also note that the ordered
comparison operators (<code>&lt;</code> <code>&lt;=</code>
<code>&gt;</code> <code>&gt;=</code>) are still undefined for
structs and arrays.

<p>
<em>Updating</em>:
This is a new feature, so existing code needs no changes.
</p>

<h3 id="funcs">Function and map equality</h3>

<p>
Go 1 disallows checking for equality of functions and maps,
respectively, except to compare them directly to <code>nil</code>.
</p>

<p>
<em>Updating</em>:
Existing code that depends on function or map equality will be
rejected by the compiler and will need to be fixed by hand.
Few programs will be affected, but the fix may require some
redesign.
</p>

<h2 id="library">Changes to the library</h2>

<h3 id="hierarchy">The package hierarchy</h3>

<p>
Go 1 has a rearranged package hierarchy that groups related items
into subdirectories. For instance, <code>utf8</code> and
<code>utf16</code> now occupy subdirectories of <code>unicode</code>.
Also, <a href="#subrepo">some packages</a> have moved into
subrepositories of
<a href="http://code.google.com/p/go"><code>code.google.com/p/go</code></a>
while <a href="#deleted">others</a> have been deleted outright.
</p>

<table class="codetable" frame="border" summary="Moved packages">
<colgroup align="left" width="60%"></colgroup>
<colgroup align="left" width="40%"></colgroup>
<tr>
<th align="left">Old path</th>
<th align="left">New path</th>
</tr>
<tr><td>asn1</td> <td>encoding/asn1</td></tr>
<tr><td>csv</td> <td>encoding/csv</td></tr>
<tr><td>gob</td> <td>encoding/gob</td></tr>
<tr><td>json</td> <td>encoding/json</td></tr>
<tr><td>xml</td> <td>encoding/xml</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>exp/template/html</td> <td>html/template</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>big</td> <td>math/big</td></tr>
<tr><td>cmath</td> <td>math/cmplx</td></tr>
<tr><td>rand</td> <td>math/rand</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>http</td> <td>net/http</td></tr>
<tr><td>http/cgi</td> <td>net/http/cgi</td></tr>
<tr><td>http/fcgi</td> <td>net/http/fcgi</td></tr>
<tr><td>http/httptest</td> <td>net/http/httptest</td></tr>
<tr><td>http/pprof</td> <td>net/http/pprof</td></tr>
<tr><td>mail</td> <td>net/mail</td></tr>
<tr><td>rpc</td> <td>net/rpc</td></tr>
<tr><td>rpc/jsonrpc</td> <td>net/rpc/jsonrpc</td></tr>
<tr><td>smtp</td> <td>net/smtp</td></tr>
<tr><td>url</td> <td>net/url</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>exec</td> <td>os/exec</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>scanner</td> <td>text/scanner</td></tr>
<tr><td>tabwriter</td> <td>text/tabwriter</td></tr>
<tr><td>template</td> <td>text/template</td></tr>
<tr><td>template/parse</td> <td>text/template/parse</td></tr>
<tr>
<td colspan="2"><hr></td>
</tr>
<tr><td>utf8</td> <td>unicode/utf8</td></tr>
<tr><td>utf16</td> <td>unicode/utf16</td></tr>
</table>

<p>
Note that the package names for the old <code>cmath</code> and
<code>exp/template/html</code> packages have changed to <code>cmplx</code>
and <code>template</code>.
</p>

<p>
<em>Updating</em>:
Gofix will update all imports and package renames for packages that
remain inside the standard repository.  Programs that import packages
that are no longer in the standard repository will need to be edited
by hand.
<font color="red">TODO: should warn about deletions.</font>
<font color="red">TODO: should also handle packages that move to subrepos.</font>
</p>

<h3 id="errors">The error type</h3>

<h3 id="errno">System call errors</h3>

<h3 id="time">Time</h3>

<h3 id="html">The html package</h3>

<h3 id="http">The http package</h3>

<h3 id="strconv">The strconv package</h3>

<h3 id="exp">The package tree exp</h3>

<h3 id="old">The package tree old</h3>

<h3 id="deleted">Deleted packages</h3>

<!-- 

moving to exp/* (and thus not in Go 1):
	ebnf, command ebnflint
	go/types, command gotype
	http/spdy
	
deleted:
	container/vector
	exp/datafmt
	go/typechecker
	try, command gotry

go/typechecker
go/types
ebnf (and cmd/ebnflint)
container/vector
try (and gotry)
exp/datafmt
netchan
-->

<h3 id="subrepo">Packages moving to subrepositories</h3>

<!-- 
crypto/openpgp to XXX
maybe exp/ssh?
-->

<h3 id="os_fileinfo">The os.FileInfo type</h3>

<h2 id="go_command">The go command</h2>

<h2 id="releases">Packaged releases</h2>