Go 1.1发行注记

Introduction to Go 1.1


The release of Go version 1 (Go 1 or Go 1.0 for short) in March of 2012 introduced a new period of stability in the Go language and libraries. That stability has helped nourish a growing community of Go users and systems around the world. Several "point" releases since then—1.0.1, 1.0.2, and 1.0.3—have been issued. These point releases fixed known bugs but made no non-critical changes to the implementation.

2012年发布的Go版本1 (简称Go 1或Go 1.0)将Go语言及其库的稳定性带入了一个新阶段。 这种稳定性的提升有助于促进全球Go用户社区及相关系统的成长。从Go 1.1开始发布了若干版本,如1.0.1、1.0.2和1.0.3, 每次都发布都会修改一些内容。但只是修改已知的Bug,而没有在实现上做关键性的改动。

This new release, Go 1.1, keeps the promise of compatibility but adds a couple of significant (backwards-compatible, of course) language changes, has a long list of (again, compatible) library changes, and includes major work on the implementation of the compilers, libraries, and run-time. The focus is on performance. Benchmarking is an inexact science at best, but we see significant, sometimes dramatic speedups for many of our test programs. We trust that many of our users' programs will also see improvements just by updating their Go installation and recompiling.

新发布的Go 1.1版本继续遵守了对兼容性的保证, 但添加了一些内容,如几个重要的语言改动(这些改动向后兼容)、对语言库的一系列改动(向后兼容) 并对编译器、语言库、运行时实现上作了较多的工作。这些改动主要关注于性能的提升。 虽然作为性能测试的基准不能完全确定,但依然能发现有显著,甚至是非常引人注目的速度提升。 我们也相信许多用户在更新其Go语言编译器并重新编译程序后,也能发现这种性能上的提升。

This document summarizes the changes between Go 1 and Go 1.1. Very little if any code will need modification to run with Go 1.1, although a couple of rare error cases surface with this release and need to be addressed if they arise. Details appear below; see the discussion of 64-bit ints and Unicode literals in particular.

本文总结了从Go 1到Go1.1的变化。从Go 1迁移到Go 1.1基本不需要对已有的代码进行修改。 但使用Go 1.1时,可能会遇到一些不常见的问题,这里有必要指出来。详细内容请参考后面 64-bit intsUnicode literals章节

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 details about some error cases that have been clarified. There are also some new language features.

Go1.1中新的编译器遵循Go兼容性文档,所以仍可继续使用Go 1语言规范编写的程序。 尽管要致力于维护Go语言规范的稳定,但针对语言规范中的一些错误仍然需要对兼容性文档进行澄清修改。这次改动也为语言添加了一些新特性。

Integer division by zero


In Go 1, integer division by a constant zero produced a run-time panic:

在Go 1中,整数除以常量零将产生运行时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.

在Go 1.1中,整数除以常量零将不再是一个合法的程序,即现在这是一个编译期错误。

Surrogates in Unicode literals

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.

细化了string和rune单字的定义,将surrogate halves排除在合法Unicode编码之外。 详细信息参考Unicode一节。

Method values


Go 1.1 now implements method values, which are functions that have been bound to a specific receiver value. For instance, given a Writer value w, the expression w.Write, a method value, is a function that will always write to w; it is equivalent to a function literal closing over w:

Go 1.1现在实现了方法值,可将函数绑定到特定接收者的值上。 例如,给定一个Writerw,表达式 w.Write即为一个方法值,作为一个向w写内容的函数,这等同于字面上附属到w上的函数。

func (p []byte) (n int, err error) {
	return w.Write(p)

Method values are distinct from method expressions, which generate functions from methods of a given type; the method expression (*bufio.Writer).Write is equivalent to a function with an extra first argument, a receiver of type (*bufio.Writer):

方法值与方法表达式不同,方法值是从方法中以给定的类型生成函数;而方法表达式 (*bufio.Writer).Write 等同于用额外的参数(即(*bufio.Writer))表示接收的类型的函数:

func (w *bufio.Writer, p []byte) (n int, err error) {
	return w.Write(p)

Updating: No existing code is affected; the change is strictly backward-compatible.


Return requirements


Before Go 1.1, a function that returned a value needed an explicit "return" or call to panic at the end of the function; this was a simple way to make the programmer be explicit about the meaning of the function. But there are many cases where a final "return" is clearly unnecessary, such as a function with only an infinite "for" loop.

在Go 1.1之前,如果要在函数中返回一个值,则需要在函数末尾显式的使用“return”或调用panic。 这可让开发者以最简单的方式理解函数的概念。但也有许多情况下明显不需要“return”,如只含有一个无限“for”循环的函数。

In Go 1.1, the rule about final "return" statements is more permissive. It introduces the concept of a terminating statement, a statement that is guaranteed to be the last one a function executes. Examples include "for" loops with no condition and "if-else" statements in which each half ends in a "return". If the final statement of a function can be shown syntactically to be a terminating statement, no final "return" statement is needed.

在Go 1.1中,对函数中最后的return语句的使用更加宽松。其引入了 终止语句 的概念,函数最后执行的必须是这条终止语句。例如无限“for”循环和只有一个return的“if-else”语句。 如果函数最后一个语句在语法上认为是终止语句,那么就不需要“return”语句了。

Note that the rule is purely syntactic: it pays no attention to the values in the code and therefore requires no complex analysis.


Updating: The change is backward-compatible, but existing code with superfluous "return" statements and calls to panic may be simplified manually. Such code can be identified by go vet.

更新:这则改动是向后兼容的,但已有代码中含有多余的“return”语句或调用panic的, 需要手动简化。可通过go vet工具标出并找到这些代码。

Changes to the implementations and tools


Status of gccgo


The GCC release schedule does not coincide with the Go release schedule, so some skew is inevitable in gccgo's releases. The 4.8.0 version of GCC shipped in March, 2013 and includes a nearly-Go 1.1 version of gccgo. Its library is a little behind the release, but the biggest difference is that method values are not implemented. Sometime around July 2013, we expect 4.8.2 of GCC to ship with a gccgo providing a complete Go 1.1 implementaiton.

GCC发行时间表与Go发行时间表并不一致,所以gccgo的发行版不可避免的与Go有些错位。2013年3月发布的GCC4.8.0版本中的gccgo支持大部分Go 1.1特性。gccgo的库的开发有点落后,但最大的不同是未实现方法值。希望在2013年5月份,能在GCC 4.8.1中看到包含对Go 1.1完整支持的gccgo

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.

在gc工具链中,编译器和链接器现在使用的是Go flag包中定义的相同的命令行参数解析规则,该规则与传统的Unix参数解析不同。 这或许会影响到直接调用工具的脚本。例如,以往的 go tool 6c -Fw -Dfoo 现在必须写为 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.

新的Go语言允许实现根据平台的不同,选择将intuint类型设为32位或64位的。 之前的Go语言实现将所有平台上的intuint固定为32位。选择gc和gccgo的实现都让intuint在AMD64/x86-64这样的64位平台拥有64位的长度。 除此之外Among other things,这也让64位的平台上的sclice可以分配超过20亿个元素。

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:

更新: 大部分程序不受这条改动的影响。由于Go不允许在不同的数值类型直接进行隐式的转换, 所以这条改动不会影响已有程序的编译,但那些隐式假设int为32位的代码可能受到影响。如下面的代码在64位系统上输出正数,在32位系统上输出负数。

x := ^uint32(0) // x is 0xffffffff
i := int(x)     // i is -1 on 32-bit systems, 0xffffffff on 64-bit
x := ^uint32(0) // x 为 0xffffffff
i := int(x)     // 在32位平台上,x为-1;在64位平台上,x为0xffffffff

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


i := int(int32(x))

Heap size on 64-bit architectures


On 64-bit architectures, the maximum heap size has been enlarged substantially, from a few gigabytes to several tens of gigabytes. (The exact details depend on the system and may change.)


On 32-bit architectures, the heap size has not changed.


Updating: This change should have no effect on existing programs beyond allowing them to run with larger heaps.

更新: 除了运行在非常大的堆上的程序,其他程序不受此更新影响。



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.

为了能表示UTF-16中大于65535的编码,Unicdoe定义了surrogate halves, 即定义一个范围的编码,用于表示UTF-16中大数值的集合。 如果出于其他目的,在代用范围内的编码是非法的。 在Go 1.1中,可通过编译器、库和运行时来获得honored by这种限制: 当以UTF-8编码时,或编码为独立的UTF-16时,surrogate half是非法的rune值。 当需要这类问题时,如将rune转成UTF-8,将其视为编码错误并转为替代的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.

在Go 1.0中输出"\ud800",但在Go 1.1中输出"\ufffd"

Surrogate-half Unicode values are now illegal in rune and string constants, so constants such as '\ud800' and "\ud800" are now rejected by the compilers. When written explicitly as UTF-8 encoded bytes, such strings can still be created, as in "\xed\xa0\x80". However, when such a string is decoded as a sequence of runes, as in a range loop, it will yield only utf8.RuneError values.

Surrogate-half Unicode值现在在rune和常量字符串中是非法的,所以编译器现在将拒绝如 '\ud800'"\ud800"这样的常量。 当遍写以UTF-8编码的字节,仍可创建这些字符串,如"\xed\xa0\x80"。 但将这样的字符串在一个范围循环中解码为rune序列时,仍将只会生成utf8.RuneError值。

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

Unicode字节顺序标志,即UTF-8下的U+FFFE下可以作为Go源码的第一个字符出现。 虽然在字节顺序未设定的 UTF-8 编码中,完全不必要这个字符,但有些编辑器会将其作为“魔法数值”添加进去, 用来标识一个UTF-8编码的文件。

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 backward-compatible.

更新: 更新:大多数程序不会受到代用改动的影响。基于旧的行为的程序应当通过修改来避免问题。字节顺序标识的变更是严格向后兼容的。

Race detector


A major addition to the tools is a race detector, a way to find bugs in programs caused by concurrent access of the same variable, where at least one of the accesses is a write. This new facility is built into the go tool. For now, it is only available on Linux, Mac OS X, and Windows systems with 64-bit x86 processors. To enable it, set the -race flag when building or testing your program (for instance, go test -race). The race detector is documented in a separate article.

Go工具中一个主要的变化是添加了竞争检测器race detector,用于检测由于同步访问一个变量, 其中至少有一个访问在进行写操作导致的bug。这个新工具已经编译进go tool中。 不过目前只能在Linux、Mac OS X和Windows 64位的x86系统上使用。可通过在构建或测试程序时,设置-race 标志来启动这个功能(例如,go test -race)。关于race detector的文档, 参考 这篇文章.

The gc assemblers


Due to the change of the int to 64 bits and a new internal representation of functions, 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.

由于将int改为64位,以及新的内部函数表示, gc工具链中,必须修改在栈中安排函数参数的方式。需要重新审视生成的汇编编写的函数,至少要调整其框架指针的偏移量。

Updating: The go vet command now checks that functions implemented in assembly match the Go function prototypes they implement.

更新: go vet命令现在可用来检查用汇编实现的函数符合其原先实现的Go函数原型。

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.

其次,在下载源码包时,不再允许go get命令将$GOROOT作为默认目标文件夹。 要使用go get时,需要一个合法的 $GOPATH

$ 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 命令时将报错。

$ GOPATH=$GOROOT go get code.google.com/p/foo/quxx
warning: GOPATH set to GOROOT (/home/you/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

Changes to the go test command

go test命令的改动

The go test command no longer deletes the binary when run with profiling enabled, to make it easier to analyze the profile. The implementation sets the -c flag automatically, so after running,

当启用profiling时,go test命令不再删除二进制文件, 因此可以更方便的分析profile。Go 1.1中默认自动设置-c,所以在运行下面代码后,

$ go test -cpuprofile cpuprof.out mypackage

the file mypackage.test will be left in the directory where go test was run.

mypackage.test文件将保留在go test运行的目录中。

The go test command can now generate profiling information that reports where goroutines are blocked, that is, where they tend to stall waiting for an event such as a channel communication. The information is presented as a blocking profile enabled with the -blockprofile option of go test. Run go help test for more information.

go test命令现在还可生成profiling信息,用于报告goroutine阻塞的 位置,即程序停下来等待某个事件的位置,如channel通讯。 这些信息以blocking profile形式表示,可通过go test-blockprofile选项启用。 可运行go help test获得更多信息。

Changes to the go fix command

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.

fix命令通常以go fix的形式使用, 不再提供将Go 1之前的代码更新到Go 1的API的功能。 如果需要将Go 1之前的代码转成Go 1.1,需要先使用Go 1.0工具链将这些代码转成Go 1.0。

Build constraints


The "go1.1" tag has been added to the list of default build constraints. This permits packages to take advantage of the new features in Go 1.1 while remaining compatible with earlier versions of Go.

go1.1”标签添加了一系列的默认的 构建约束。 这允许函数包即可利用Go 1.1新特性的优点,也保留对早期Go版本的支持。

To build a file only with Go 1.1 and above, add this build constraint:


// +build go1.1

To build a file only with Go 1.0.x, use the converse constraint:

若要构建只支持Go 1.0.x的文件,使用相反的约束:

// +build !go1.1

Additional platforms


The Go 1.1 tool chain adds experimental support for freebsd/arm, netbsd/386, netbsd/amd64, netbsd/arm, openbsd/386 and openbsd/amd64 platforms.

Go 1.1 工具链实验性的支持freebsd/armnetbsd/386netbsd/amd64netbsd/arm, openbsd/386openbsd/amd64平台。

An ARMv6 or later processor is required for freebsd/arm or netbsd/arm.

针对ARMv6或以后的处理器,需要使用freebsd/arm or netbsd/arm

Go 1.1 adds experimental support for cgo on linux/arm.

Go 1.1为linux/arm提供了实现性的 cgo支持。

Cross compilation


When cross-compiling, the go tool will disable cgo support by default.


To explicitly enable cgo, set CGO_ENABLED=1.




The performance of code compiled with the Go 1.1 gc tool suite should be noticeably better for most Go programs. Typical improvements relative to Go 1.0 seem to be about 30%-40%, sometimes much more, but occasionally less or even non-existent. There are too many small performance-driven tweaks through the tools and libraries to list them all here, but the following major changes are worth noting:

对于大部分Go程序来说,使用Go 1.1 gc工具套件编译的代码将有显著的性能提升。 一般来说,与Go 1.0相比,Go 1.1将带来30%-40%的性能提升,有时候会更多,但偶尔也会有出现提升很少甚至没有提升的情况。 对工具和库有太多小的性能上的改动,无法在这一一列举,不过这里还是列出一些值得关注的改动:

  • The gc compilers generate better code in many cases, most noticeably for floating point on the 32-bit Intel architecture.
  • The gc compilers do more in-lining, including for some operations in the run-time such as append and interface conversions.
  • There is a new implementation of Go maps with significant reduction in memory footprint and CPU time.
  • The garbage collector has been made more parallel, which can reduce latencies for programs running on multiple CPUs.
  • The garbage collector is also more precise, which costs a small amount of CPU time but can reduce the size of the heap significantly, especially on 32-bit architectures.
  • Due to tighter coupling of the run-time and network libraries, fewer context switches are required on network operations.

Changes to the standard library



The various routines to scan textual input in the bufio package, ReadBytes, ReadString and particularly ReadLine, are needlessly complex to use for simple purposes. In Go 1.1, a new type, Scanner, has been added to make it easier to do simple tasks such as read the input as a sequence of lines or space-delimited words. It simplifies the problem by terminating the scan on problematic input such as pathologically long lines, and having a simple default: line-oriented input, with each line stripped of its terminator. Here is code to reproduce the input a line at a time:

在进行简单操作时,bufio包中许多处理文本输入的函数如 ReadBytesReadString, 特别是ReadLine都显的过于复杂。 在Go 1.1中,新添加了Scanner类型。可方便的用于进行简单的输入操作, 如将输入读取为一行或空格终止的字符。例如遇到有问题的很长的文本行,可以通过终止读取来简化这些问题的处理,该类型也提供了简单的默认行为:基于行的输入,读取的每一行都剔除了分隔标识。下面的代码展示了每次输入一行的方法:

scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
    fmt.Println(scanner.Text()) // Println will add back the final '\n'
if err := scanner.Err(); err != nil {
    fmt.Fprintln(os.Stderr, "reading standard input:", err)

Scanning behavior can be adjusted through a function to control subdividing the input (see the documentation for SplitFunc), but for tough problems or the need to continue past errors, the older interface may still be required.



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.

之前,在net包中针对特定协议的解析器对传递入的网络名很宽松。虽然文档明确指出对于ResolveTCPAddr合法的网络名只有"tcp""tcp4""tcp6",但在Go 1.0的实现中可接受任何字符串。而Go 1.1的实现,如果网络名不是上面列出的这些字符串,就会返回一个错误。对于其他特定协议的解析器,如ResolveIPAddrResolveUDPAddrResolveUnixAddr也是一样。

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.

在之前ListenUnixgram的实现中,其返回一个 UDPConn作为接收连接的端点。 在Go 1.1的实现里,用UnixConn来代替,这允许用它的 ReadFromWriteTo方法读写。

The data structures IPAddr, TCPAddr, and UDPAddr add a new string field called Zone. Code using untagged composite literals (e.g. net.TCPAddr{ip, port}) instead of tagged literals (net.TCPAddr{IP: ip, Port: port}) will break due to the new field. The Go 1 compatibility rules allow this change: client code must use tagged literals to avoid such breakages.

数据结构IPAddrTCPAddrUDPAddr 添加了一个名为Zone的新的字符串字段。 如果代码使用没有标签的复合文法(例如net.TCPAddr{ip, port}), 而不是有标签的文法(net.TCPAddr{IP: ip, Port: port}),那么由于这个新字段,程序将出错。 Go1的兼容性规则允许这个变化:客户端代码必须使用标签化的文法以避免这种破坏。

Updating: To correct breakage caused by the new struct field, go fix will rewrite code to add tags for these types. More generally, go vet will identify composite literals that should be revised to use field tags.

更新: 为了修正由于新的结构体字段带来的破坏,go fix将会重写这些类型的代码并添加标签。 更普遍的方法是通过go vet标识出所有应当使用字段标签的复合文法。


The reflect package has several significant additions.


It is now possible to run a "select" statement using the reflect package; see the description of Select and SelectCase for details.


The new method Value.Convert (or Type.ConvertibleTo) provides functionality to execute a Go conversion or type assertion operation on a Value (or test for its possibility).

新的方法Value.Convert (或Type.ConvertibleTo) 提供了对Value进行Go转换和类型断言操作(或者是检测这种可能性)的功能。

The new function MakeFunc creates a wrapper function to make it easier to call a function with existing Values, doing the standard Go conversions among the arguments, for instance to pass an actual int to a formal interface{}.

新函数MakeFunc创建了封装函数, 可更方便的在已有Values上调用函数, 该封装函数可用于标准的Go参数的转换,例如将一个int传递为interface{}。

Finally, the new functions ChanOf, MapOf and SliceOf construct new Types from existing types, for example to construct the type []T given only T.

最后,新函数 ChanOfMapOfSliceOf 可以从已有类型中构造新Types,例如在仅提供[]T的情况下构造[]T


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.

在FreeBSD, Linux, NetBSD, OS X and OpenBSD上,以前版本的time包以微秒的精度返回时间。 现在在Go 1.1的实现中,以纳秒为精度返回时间。 程序以微秒为精度向外部格式写入时间并再次读取,可能希望恢复原先的值,但由于精度问题将产生损失。 Time有两个新方法, RoundTruncate ,可以用来在向外部存储写入时间前,从时间里去除精度。

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.

Timer类型有一个新方法 Reset,让定时器在指定的间隔后过期。

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.

最后,一个新函数ParseInLocation 与已有的Parse类似, 如果传入的字符串中包含有时区信息,这个函数会忽略解析的字符串中的时区信息。 这个函数解决了时间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

为了在需要的时候让用户更方便的访问软件的二进制发布版,在二进制发布版中将不包括expold子源码树,这些源码移动到code.google.com/p/go.exp上的go.exp子版本库中。 如要访问ssa包,如下,运行

$ 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.

旧的包exp/norm也迁移到了新的版本库go.text中,这里包含了将要开发的Unicode API和其他文本相关的包。

New packages


There are three new packages.

Go 1.1中新添加了3个函数包.

  • The go/format package provides a convenient way for a program to access the formatting capabilities of the go fmt command. It has two functions, Node to format a Go parser Node, and Source to reformat arbitrary Go source code into the standard format as provided by the go fmt command.
  • The net/http/cookiejar package provides the basics for managing HTTP cookies.
  • The runtime/race package provides low-level facilities for data race detection. It is internal to the race detector and does not otherwise export any user-visible functionality.

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.