For a full explanation of the motivation and design of Go 1, see XXX. Here follows a summary.
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.
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
go 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.
The append built-in function is variadic, so one can
append to a byte slice using the ... syntax in the
call.
greeting := []byte{}
greeting = append(greeting, []byte("hello ")...)
By analogy with the similar property of copy, Go 1
permits a string to be appended (byte-wise) directly to a byte
slice; the conversion is no longer necessary:
greeting = append(greeting, "world"...)
Updating: This is a new feature, so existing code needs no changes.
The close 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 close on a receive-only channel:
var c chan int
var csend chan<- int = c
var crecv <-chan int = c
close(c) // legal
close(csend) // legal
close(crecv) // illegal
Updating: 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.
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.
type Date struct {
month string
day int
}
// Struct values, fully qualified; always legal.
holiday1 := []Date{
Date{"Feb", 14},
Date{"Nov", 11},
Date{"Dec", 25},
}
// Struct values, type name elided; always legal.
holiday2 := []Date{
{"Feb", 14},
{"Nov", 11},
{"Dec", 25},
}
// Pointers, fully qualified, always legal.
holiday3 := []*Date{
&Date{"Feb", 14},
&Date{"Nov", 11},
&Date{"Dec", 25},
}
// Pointers, type name elided; legal in Go 1.
holiday4 := []*Date{
{"Feb", 14},
{"Nov", 11},
{"Dec", 25},
}
Updating:
This change has no effect on existing code, but the command
gofmt -s applied to existing source
will, among other things, elide explicit element types wherever permitted.
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
init routines and global initialization expressions
without introducing a deadlock.
var PackageGlobal int
func init() {
c := make(chan int)
go initializationFunction(c)
PackageGlobal = <-c
}
Updating:
This is a new feature, so existing code needs no changes,
although it's possible that code that depends on goroutines not starting before main will break.
There was no such code in the standard repository.
Go 1 introduces a new basic type, rune, to be used to represent
individual Unicode code points.
It is an alias for int32, analogous to byte
as an alias for uint8.
Character literals such as 'a', '語', and '\u0345'
now have default type rune,
analogous to 1.0 having default type float64.
A variable initialized to a character constant will therefore
have type rune unless otherwise specified.
Libraries have been updated to use rune rather than int
when appropriate. For instance, the functions unicode.ToLower and
relatives now take and return a rune.
delta := 'δ' // delta has type rune.
var DELTA rune
DELTA = unicode.ToUpper(delta)
epsilon := unicode.ToLower(DELTA + 1)
if epsilon != 'δ'+1 {
log.Fatal("inconsistent casing for Greek")
}
Updating:
Most source code will be unaffected by this because the type inference from
:= initializers introduces the new type silently, and it propagates
from there.
Some code may get type errors that a trivial conversion will resolve.
Go 1 introduces a new built-in type, error, which has the following definition:
type error interface {
Error() string
}
Since the consequences of this type are all in the package library, it is discussed below.
The original syntax for deleting an element in a map was:
m[k] = ignored, false
In Go 1, that syntax has gone; instead there is a new built-in
function, delete. The call
delete(m, k)
will delete the map entry retrieved by the expression m[k].
There is no return value. Deleting a non-existent entry is a no-op.
Updating:
Gofix will convert expressions of the form m[k] = ignored,
false into delete(m, k) when it is clear that
the ignored value can be safely discarded from the program and
false refers to the predefined boolean constant. Gofix
will flag other uses of the syntax for inspection by the programmer.
In Go 1, the order in which elements are visited when iterating
over a map using a for range 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.
m := map[string]int{"Sunday": 0, "Monday": 1}
for name, value := range m {
// This loop should not assume Sunday will be visited first.
f(name, value)
}
Updating: 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.
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.
These examples illustrate the behavior.
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)
Updating: 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.
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.)
This function implicitly returns a shadowed return value and will be rejected by the compiler:
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.
}
Updating: 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.
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.
As an example, if package p includes the definitions,
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)
}
a package that imports p can assign and copy values of type
p.Struct 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
import "p"
myStruct := p.NewStruct(23)
copyOfMyStruct := myStruct
fmt.Println(myStruct, copyOfMyStruct)
will show that the secret field of the struct has been copied to the new value.
Updating: This is a new feature, so existing code needs no changes.
Go 1 defines equality and inequality (== and
!=) 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).
As a result, structs and arrays can now be used as map keys:
// type Day struct {
// long string
// short string
// }
// Christmas := Day{"Christmas", "XMas"}
// Thanksgiving := Day{"Thanksgiving", "Turkey"}
// holiday := map[Day]bool {
// Christmas: true,
// Thanksgiving: true,
// }
// fmt.Printf("Christmas is a holiday: %t\n", holiday[Christmas])
Note that equality is still undefined for slices, for which the
calculation is in general infeasible. Also note that the ordered
comparison operators (< <=
> >=) are still undefined for
structs and arrays.
Updating: This is a new feature, so existing code needs no changes.
Go 1 disallows checking for equality of functions and maps,
respectively, except to compare them directly to nil.
Updating: 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.
Go 1 has a rearranged package hierarchy that groups related items
into subdirectories. For instance, utf8 and
utf16 now occupy subdirectories of unicode.
Also, some packages have moved into
subrepositories of
code.google.com/p/go
while others have been deleted outright.
| Old path | New path |
|---|---|
| asn1 | encoding/asn1 |
| csv | encoding/csv |
| gob | encoding/gob |
| json | encoding/json |
| xml | encoding/xml |
| exp/template/html | html/template |
| big | math/big |
| cmath | math/cmplx |
| rand | math/rand |
| http | net/http |
| http/cgi | net/http/cgi |
| http/fcgi | net/http/fcgi |
| http/httptest | net/http/httptest |
| http/pprof | net/http/pprof |
| net/mail | |
| rpc | net/rpc |
| rpc/jsonrpc | net/rpc/jsonrpc |
| smtp | net/smtp |
| url | net/url |
| exec | os/exec |
| scanner | text/scanner |
| tabwriter | text/tabwriter |
| template | text/template |
| template/parse | text/template/parse |
| utf8 | unicode/utf8 |
| utf16 | unicode/utf16 |
Note that the package names for the old cmath and
exp/template/html packages have changed to cmplx
and template.
Updating: 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. TODO: should warn about deletions. TODO: should also handle packages that move to subrepos.