Introduction to Go 1.1

TODO - overview - link back to Go 1 and also Go 1 Compatibility docs.

Changes to the language

The Go compatibility document promises that programs written to the Go 1 language specification will continue to operate, and those promises are maintained. In the interest of firming up the specification, though, there are some details about some error cases that have been clarified. There is also some new language features.

Integer division by zero

In Go 1, integer division by a constant zero produced a runtime panic:

func f(x int) int {
	return x/0
}

In Go 1.1, an integer division by constant zero is not a legal program, so it is a compile-time error.

Surrogates in Unicode literals

The definition of string and rune literals has been refined to exclude surrogate halves from the set of valid Unicode code points. See the Unicode section for more information.

Method values

TODO

Return requirements

TODO

Changes to the implementations and tools

TODO: more

Command-line flag parsing

In the gc tool chain, the compilers and linkers now use the same command-line flag parsing rules as the Go flag package, a departure from the traditional Unix flag parsing. This may affect scripts that invoke the tool directly. For example, go tool 6c -Fw -Dfoo must now be written go tool 6c -F -w -D foo.

Size of int on 64-bit platforms

The language allows the implementation to choose whether the int type and uint types are 32 or 64 bits. Previous Go implementations made int and uint 32 bits on all systems. Both the gc and gccgo implementations now make int and uint 64 bits on 64-bit platforms such as AMD64/x86-64. Among other things, this enables the allocation of slices with more than 2 billion elements on 64-bit platforms.

Updating: Most programs will be unaffected by this change. Because Go does not allow implicit conversions between distinct numeric types, no programs will stop compiling due to this change. However, programs that contain implicit assumptions that int is only 32 bits may change behavior. For example, this code prints a positive number on 64-bit systems and a negative one on 32-bit systems:

x := ^uint32(0) // x is 0xffffffff
i := int(x)     // i is -1 on 32-bit systems, 0xffffffff on 64-bit
fmt.Println(i)

Portable code intending 32-bit sign extension (yielding -1 on all systems) would instead say:

i := int(int32(x))

Unicode

To make it possible to represent code points greater than 65535 in UTF-16, Unicode defines surrogate halves, a range of code points to be used only in the assembly of large values, and only in UTF-16. The code points in that surrogate range are illegal for any other purpose. In Go 1.1, this constraint is honored by the compiler, libraries, and run-time: a surrogate half is illegal as a rune value, when encoded as UTF-8, or when encoded in isolation as UTF-16. When encountered, for example in converting from a rune to UTF-8, it is treated as an encoding error and will yield the replacement rune, utf8.RuneError, U+FFFD.

This program,

import "fmt"

func main() {
    fmt.Printf("%+q\n", string(0xD800))
}

printed "\ud800" in Go 1.0, but prints "\ufffd" in Go 1.1.

The Unicode byte order marks U+FFFE and U+FEFF, encoded in UTF-8, are now permitted as the first character of a Go source file. Even though their appearance in the byte-order-free UTF-8 encoding is clearly unnecessary, some editors add them as a kind of "magic number" identifying a UTF-8 encoded file.

Updating: Most programs will be unaffected by the surrogate change. Programs that depend on the old behavior should be modified to avoid the issue. The byte-order-mark change is strictly backwards-compatible.

The gc assemblers

Due to the change of the int to 64 bits and some other changes, the arrangement of function arguments on the stack has changed in the gc tool chain. Functions written in assembly will need to be revised at least to adjust frame pointer offsets.

TODO: Point to cmd/vet once it handles this.

Changes to the go command

The go command has acquired several changes intended to improve the experience for new Go users.

First, when compiling, testing, or running Go code, the go command will now give more detailed error messages, including a list of paths searched, when a package cannot be located.

$ go build foo/quxx
can't load package: package foo/quxx: cannot find package "foo/quxx" in any of:
        /home/you/go/src/pkg/foo/quxx (from $GOROOT)
        /home/you/src/foo/quxx (from $GOPATH) 

Second, the go get command no longer allows $GOROOT as the default destination when downloading package source. To use the go get command, a valid $GOPATH is now required.

$ GOPATH= go get code.google.com/p/foo/quxx
package code.google.com/p/foo/quxx: cannot download, $GOPATH not set. For more details see: go help gopath 

Finally, as a result of the previous change, the go get command will also fail when $GOPATH and $GOROOT are set to the same value.

$ GOPATH=$GOROOT go get code.google.com/p/foo/quxx
warning: GOPATH set to GOROOT (/home/User/go) has no effect
package code.google.com/p/foo/quxx: cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath

TODO: go test uses -c with a profile flag.

Changes to go fix

The fix command, usually run as go fix, no longer applies fixes to update code from before Go 1 to use Go 1 APIs. To update pre-Go 1 code to Go 1.1, use a Go 1.0 tool chain to convert the code to Go 1.0 first.

Performance

TODO introduction

Changes to the standard library

bufio.Scanner

TODO

debug/elf

TODO: Decide whether to keep this change. See CL 6848044.

Previous versions of the debug/elf package intentionally skipped over the first symbol in the ELF symbol table, since it is always an empty symbol. This symbol is no longer skipped since indexes into the symbol table returned by debug/elf will be different from indexes into the original ELF symbol table. Any code that calls the methods Symbols or ImportedSymbols of the elf.File type may need to be adjusted to account for the additional symbol and the change in symbol offsets.

net

The protocol-specific resolvers in the net package were formerly lax about the network name passed in. Although the documentation was clear that the only valid networks for ResolveTCPAddr are "tcp", "tcp4", and "tcp6", the Go 1.0 implementation silently accepted any string. The Go 1.1 implementation returns an error if the network is not one of those strings. The same is true of the other protocol-specific resolvers ResolveIPAddr, ResolveUDPAddr, and ResolveUnixAddr.

The previous implementation of ListenUnixgram returned a UDPConn as a representation of the connection endpoint. The Go 1.1 implementation instead returns a UnixConn to allow reading and writing with its ReadFrom and WriteTo methods.

reflect

TODO: reflect: Select, ChanOf, MakeFunc, MapOf, SliceOf, Convert, Type.ConvertibleTo

runtime

TODO: runtime: BlockProfile

time

On FreeBSD, Linux, NetBSD, OS X and OpenBSD, previous versions of the time package returned times with microsecond precision. The Go 1.1 implementation on these systems now returns times with nanosecond precision. Programs that write to an external format with microsecond precision and read it back, expecting to recover the original value, will be affected by the loss of precision. There are two new methods of Time, Round and Truncate, that can be used to remove precision from a time before passing it to external storage.

The new method YearDay returns the one-indexed integral day number of the year specified by the time value.

The Timer type has a new method Reset that modifies the timer to expire after a specified duration.

Finally, the new function ParseInLocation is like the existing Parse but parses the time in the context of a location (time zone), ignoring time zone information in the parsed string. This function addresses a common source of confusion in the time API.

Updating: Code that needs to read and write times using an external format with lower precision should be modified to use the new methods.

Exp and old subtrees moved to go.exp and go.text subrepositories

To make it easier for binary distributions to access them if desired, the exp and old source subtrees, which are not included in binary distributions, have been moved to the new go.exp subrepository at code.google.com/p/go.exp. To access the ssa package, for example, run

$ go get code.google.com/p/go.exp/ssa

and then in Go source,

import "code.google.com/p/go.exp/ssa"

The old package exp/norm has also been moved, but to a new repository go.text, where the Unicode APIs and other text-related packages will be developed.

Minor changes to the library

The following list summarizes a number of minor changes to the library, mostly additions. See the relevant package documentation for more information about each change.