diff options
Diffstat (limited to 'doc/go1.4.html')
| -rw-r--r-- | doc/go1.4.html | 896 |
1 files changed, 896 insertions, 0 deletions
diff --git a/doc/go1.4.html b/doc/go1.4.html new file mode 100644 index 000000000..b4f9619bb --- /dev/null +++ b/doc/go1.4.html @@ -0,0 +1,896 @@ +<!--{ + "Title": "Go 1.4 Release Notes", + "Path": "/doc/go1.4", + "Template": true +}--> + +<h2 id="introduction">Introduction to Go 1.4</h2> + +<p> +The latest Go release, version 1.4, arrives as scheduled six months after 1.3. +</p> + +<p> +It contains only one tiny language change, +in the form of a backwards-compatible simple variant of <code>for</code>-<code>range</code> loop, +and a possibly breaking change to the compiler involving methods on pointers-to-pointers. +</p> + +<p> +The release focuses primarily on implementation work, improving the garbage collector +and preparing the ground for a fully concurrent collector to be rolled out in the +next few releases. +Stacks are now contiguous, reallocated when necessary rather than linking on new +"segments"; +this release therefore eliminates the notorious "hot stack split" problem. +There are some new tools available including support in the <code>go</code> command +for build-time source code generation. +The release also adds support for ARM processors on Android and Native Client (NaCl) +and for AMD64 on Plan 9. +</p> + +<p> +As always, Go 1.4 keeps the <a href="/doc/go1compat.html">promise +of compatibility</a>, +and almost everything +will continue to compile and run without change when moved to 1.4. +</p> + +<h2 id="language">Changes to the language</h2> + +<h3 id="forrange">For-range loops</h3> +<p> +Up until Go 1.3, <code>for</code>-<code>range</code> loop had two forms +</p> + +<pre> +for i, v := range x { + ... +} +</pre> + +<p> +and +</p> + +<pre> +for i := range x { + ... +} +</pre> + +<p> +If one was not interested in the loop values, only the iteration itself, it was still +necessary to mention a variable (probably the <a href="/ref/spec#Blank_identifier">blank identifier</a>, as in +<code>for</code> <code>_</code> <code>=</code> <code>range</code> <code>x</code>), because +the form +</p> + +<pre> +for range x { + ... +} +</pre> + +<p> +was not syntactically permitted. +</p> + +<p> +This situation seemed awkward, so as of Go 1.4 the variable-free form is now legal. +The pattern arises rarely but the code can be cleaner when it does. +</p> + +<p> +<em>Updating</em>: The change is strictly backwards compatible to existing Go +programs, but tools that analyze Go parse trees may need to be modified to accept +this new form as the +<code>Key</code> field of <a href="/pkg/go/ast/#RangeStmt"><code>RangeStmt</code></a> +may now be <code>nil</code>. +</p> + +<h3 id="methodonpointertopointer">Method calls on **T</h3> + +<p> +Given these declarations, +</p> + +<pre> +type T int +func (T) M() {} +var x **T +</pre> + +<p> +both <code>gc</code> and <code>gccgo</code> accepted the method call +</p> + +<pre> +x.M() +</pre> + +<p> +which is a double dereference of the pointer-to-pointer <code>x</code>. +The Go specification allows a single dereference to be inserted automatically, +but not two, so this call is erroneous according to the language definition. +It has therefore been disallowed in Go 1.4, which is a breaking change, +although very few programs will be affected. +</p> + +<p> +<em>Updating</em>: Code that depends on the old, erroneous behavior will no longer +compile but is easy to fix by adding an explicit dereference. +</p> + +<h2 id="os">Changes to the supported operating systems and architectures</h2> + +<h3 id="android">Android</h3> + +<p> +Go 1.4 can build binaries for ARM processors running the Android operating system. +It can also build a <code>.so</code> library that can be loaded by an Android application +using the supporting packages in the <a href="https://golang.org/x/mobile">mobile</a> subrepository. +A brief description of the plans for this experimental port are available +<a href="https://golang.org/s/go14android">here</a>. +</p> + +<h3 id="naclarm">NaCl on ARM</h3> + +<p> +The previous release introduced Native Client (NaCl) support for the 32-bit x86 +(<code>GOARCH=386</code>) +and 64-bit x86 using 32-bit pointers (GOARCH=amd64p32). +The 1.4 release adds NaCl support for ARM (GOARCH=arm). +</p> + +<h3 id="plan9amd64">Plan9 on AMD64</h3> + +<p> +This release adds support for the Plan 9 operating system on AMD64 processors, +provided the kernel supports the <code>nsec</code> system call and uses 4K pages. +</p> + +<h2 id="compatibility">Changes to the compatibility guidelines</h2> + +<p> +The <a href="/pkg/unsafe/"><code>unsafe</code></a> package allows one +to defeat Go's type system by exploiting internal details of the implementation +or machine representation of data. +It was never explicitly specified what use of <code>unsafe</code> meant +with respect to compatibility as specified in the +<a href="go1compat.html">Go compatibility guidelines</a>. +The answer, of course, is that we can make no promise of compatibility +for code that does unsafe things. +</p> + +<p> +We have clarified this situation in the documentation included in the release. +The <a href="go1compat.html">Go compatibility guidelines</a> and the +docs for the <a href="/pkg/unsafe/"><code>unsafe</code></a> package +are now explicit that unsafe code is not guaranteed to remain compatible. +</p> + +<p> +<em>Updating</em>: Nothing technical has changed; this is just a clarification +of the documentation. +</p> + + +<h2 id="impl">Changes to the implementations and tools</h2> + +<h3 id="runtime">Changes to the runtime</h3> + +<p> +Prior to Go 1.4, the runtime (garbage collector, concurrency support, interface management, +maps, slices, strings, ...) was mostly written in C, with some assembler support. +In 1.4, much of the code has been translated to Go so that the garbage collector can scan +the stacks of programs in the runtime and get accurate information about what variables +are active. +This change was large but should have no semantic effect on programs. +</p> + +<p> +This rewrite allows the garbage collector in 1.4 to be fully precise, +meaning that it is aware of the location of all active pointers in the program. +This means the heap will be smaller as there will be no false positives keeping non-pointers alive. +Other related changes also reduce the heap size, which is smaller by 10%-30% overall +relative to the previous release. +</p> + +<p> +A consequence is that stacks are no longer segmented, eliminating the "hot split" problem. +When a stack limit is reached, a new, larger stack is allocated, all active frames for +the goroutine are copied there, and any pointers into the stack are updated. +Performance can be noticeably better in some cases and is always more predictable. +Details are available in <a href="https://golang.org/s/contigstacks">the design document</a>. +</p> + +<p> +The use of contiguous stacks means that stacks can start smaller without triggering performance issues, +so the default starting size for a goroutine's stack in 1.4 has been reduced from 8192 bytes to 2048 bytes. +</p> + +<p> +As preparation for the concurrent garbage collector scheduled for the 1.5 release, +writes to pointer values in the heap are now done by a function call, +called a write barrier, rather than directly from the function updating the value. +In this next release, this will permit the garbage collector to mediate writes to the heap while it is running. +This change has no semantic effect on programs in 1.4, but was +included in the release to test the compiler and the resulting performance. +</p> + +<p> +The implementation of interface values has been modified. +In earlier releases, the interface contained a word that was either a pointer or a one-word +scalar value, depending on the type of the concrete object stored. +This implementation was problematical for the garbage collector, +so as of 1.4 interface values always hold a pointer. +In running programs, most interface values were pointers anyway, +so the effect is minimal, but programs that store integers (for example) in +interfaces will see more allocations. +</p> + +<p> +As of Go 1.3, the runtime crashes if it finds a memory word that should contain +a valid pointer but instead contains an obviously invalid pointer (for example, the value 3). +Programs that store integers in pointer values may run afoul of this check and crash. +In Go 1.4, setting the <a href="/pkg/runtime/"><code>GODEBUG</code></a> variable +<code>invalidptr=0</code> disables +the crash as a workaround, but we cannot guarantee that future releases will be +able to avoid the crash; the correct fix is to rewrite code not to alias integers and pointers. +</p> + +<h3 id="asm">Assembly</h3> + +<p> +The language accepted by the assemblers <code>cmd/5a</code>, <code>cmd/6a</code> +and <code>cmd/8a</code> has had several changes, +mostly to make it easier to deliver type information to the runtime. +</p> + +<p> +First, the <code>textflag.h</code> file that defines flags for <code>TEXT</code> directives +has been copied from the linker source directory to a standard location so it can be +included with the simple directive +</p> + +<pre> +#include "textflag.h" +</pre> + +<p> +The more important changes are in how assembler source can define the necessary +type information. +For most programs it will suffice to move data +definitions (<code>DATA</code> and <code>GLOBL</code> directives) +out of assembly into Go files +and to write a Go declaration for each assembly function. +The <a href="/doc/asm#runtime">assembly document</a> describes what to do. +</p> + +<p> +<em>Updating</em>: +Assembly files that include <code>textflag.h</code> from its old +location will still work, but should be updated. +For the type information, most assembly routines will need no change, +but all should be examined. +Assembly source files that define data, +functions with non-empty stack frames, or functions that return pointers +need particular attention. +A description of the necessary (but simple) changes +is in the <a href="/doc/asm#runtime">assembly document</a>. +</p> + +<p> +More information about these changes is in the <a href="/doc/asm">assembly document</a>. +</p> + +<h3 id="gccgo">Status of gccgo</h3> + +<p> +The release schedules for the GCC and Go projects do not coincide. +GCC release 4.9 contains the Go 1.2 version of gccgo. +The next release, GCC 5, will likely have the Go 1.4 version of gccgo. +</p> + +<h3 id="internalpackages">Internal packages</h3> + +<p> +Go's package system makes it easy to structure programs into components with clean boundaries, +but there are only two forms of access: local (unexported) and global (exported). +Sometimes one wishes to have components that are not exported, +for instance to avoid acquiring clients of interfaces to code that is part of a public repository +but not intended for use outside the program to which it belongs. +</p> + +<p> +The Go language does not have the power to enforce this distinction, but as of Go 1.4 the +<a href="/cmd/go/"><code>go</code></a> command introduces +a mechanism to define "internal" packages that may not be imported by packages outside +the source subtree in which they reside. +</p> + +<p> +To create such a package, place it in a directory named <code>internal</code> or in a subdirectory of a directory +named internal. +When the <code>go</code> command sees an import of a package with <code>internal</code> in its path, +it verifies that the package doing the import +is within the tree rooted at the parent of the <code>internal</code> directory. +For example, a package <code>.../a/b/c/internal/d/e/f</code> +can be imported only by code in the directory tree rooted at <code>.../a/b/c</code>. +It cannot be imported by code in <code>.../a/b/g</code> or in any other repository. +</p> + +<p> +For Go 1.4, the internal package mechanism is enforced for the main Go repository; +from 1.5 and onward it will be enforced for any repository. +</p> + +<p> +Full details of the mechanism are in +<a href="https://golang.org/s/go14internal">the design document</a>. +</p> + +<h3 id="canonicalimports">Canonical import paths</h3> + +<p> +Code often lives in repositories hosted by public services such as <code>github.com</code>, +meaning that the import paths for packages begin with the name of the hosting service, +<code>github.com/rsc/pdf</code> for example. +One can use +<a href="/cmd/go/#hdr-Remote_import_paths">an existing mechanism</a> +to provide a "custom" or "vanity" import path such as +<code>rsc.io/pdf</code>, but +that creates two valid import paths for the package. +That is a problem: one may inadvertently import the package through the two +distinct paths in a single program, which is wasteful; +miss an update to a package because the path being used is not recognized to be +out of date; +or break clients using the old path by moving the package to a different hosting service. +</p> + +<p> +Go 1.4 introduces an annotation for package clauses in Go source that identify a canonical +import path for the package. +If an import is attempted using a path that is not canonical, +the <a href="/cmd/go/"><code>go</code></a> command +will refuse to compile the importing package. +</p> + +<p> +The syntax is simple: put an identifying comment on the package line. +For our example, the package clause would read: +</p> + +<pre> +package pdf // import "rsc.io/pdf" +</pre> + +<p> +With this in place, +the <code>go</code> command will +refuse to compile a package that imports <code>github.com/rsc/pdf</code>, +ensuring that the code can be moved without breaking users. +</p> + +<p> +The check is at build time, not download time, so if <code>go</code> <code>get</code> +fails because of this check, the mis-imported package has been copied to the local machine +and should be removed manually. +</p> + +<p> +To complement this new feature, a check has been added at update time to verify +that the local package's remote repository matches that of its custom import. +The <code>go</code> <code>get</code> <code>-u</code> command will fail to +update a package if its remote repository has changed since it was first +downloaded. +The new <code>-f</code> flag overrides this check. +</p> + +<p> +Further information is in +<a href="https://golang.org/s/go14customimport">the design document</a>. +</p> + +<h3 id="subrepo">Import paths for the subrepositories</h3> + +<p> +The Go project subrepositories (<code>code.google.com/p/go.tools</code> and so on) +are now available under custom import paths replacing <code>code.google.com/p/go.</code> with <code>golang.org/x/</code>, +as in <code>golang.org/x/tools</code>. +We will add canonical import comments to the code around June 1, 2015, +at which point Go 1.4 and later will stop accepting the old <code>code.google.com</code> paths. +</p> + +<p> +<em>Updating</em>: All code that imports from subrepositories should change +to use the new <code>golang.org</code> paths. +Go 1.0 and later can resolve and import the new paths, so updating will not break +compatibility with older releases. +Code that has not updated will stop compiling with Go 1.4 around June 1, 2015. +</p> + +<h3 id="gogenerate">The go generate subcommand</h3> + +<p> +The <a href="/cmd/go/"><code>go</code></a> command has a new subcommand, +<a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go generate</code></a>, +to automate the running of tools to generate source code before compilation. +For example, it can be used to run the <a href="/cmd/yacc"><code>yacc</code></a> +compiler-compiler on a <code>.y</code> file to produce the Go source file implementing the grammar, +or to automate the generation of <code>String</code> methods for typed constants using the new +<a href="http://godoc.org/golang.org/x/tools/cmd/stringer">stringer</a> +tool in the <code>golang.org/x/tools</code> subrepository. +</p> + +<p> +For more information, see the +<a href="https://golang.org/s/go1.4-generate">design document</a>. +</p> + +<h3 id="filenames">Change to file name handling</h3> + +<p> +Build constraints, also known as build tags, control compilation by including or excluding files +(see the documentation <a href="/pkg/go/build/"><code>/go/build</code></a>). +Compilation can also be controlled by the name of the file itself by "tagging" the file with +a suffix (before the <code>.go</code> or <code>.s</code> extension) with an underscore +and the name of the architecture or operating system. +For instance, the file <code>gopher_arm.go</code> will only be compiled if the target +processor is an ARM. +</p> + +<p> +Before Go 1.4, a file called just <code>arm.go</code> was similarly tagged, but this behavior +can break sources when new architectures are added, causing files to suddenly become tagged. +In 1.4, therefore, a file will be tagged in this manner only if the tag (architecture or operating +system name) is preceded by an underscore. +</p> + +<p> +<em>Updating</em>: Packages that depend on the old behavior will no longer compile correctly. +Files with names like <code>windows.go</code> or <code>amd64.go</code> should either +have explicit build tags added to the source or be renamed to something like +<code>os_windows.go</code> or <code>support_amd64.go</code>. +</p> + +<h3 id="gocmd">Other changes to the go command</h3> + +<p> +There were a number of minor changes to the +<a href="/cmd/go/"><code>cmd/go</code></a> +command worth noting. +</p> + +<ul> + +<li> +Unless <a href="/cmd/cgo/"><code>cgo</code></a> is being used to build the package, +the <code>go</code> command now refuses to compile C source files, +since the relevant C compilers +(<a href="/cmd/6c/"><code>6c</code></a> etc.) +are intended to be removed from the installation in some future release. +(They are used today only to build part of the runtime.) +It is difficult to use them correctly in any case, so any extant uses are likely incorrect, +so we have disabled them. +</li> + +<li> +The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a> +subcommand has a new flag, <code>-o</code>, to set the name of the resulting binary, +corresponding to the same flag in other subcommands. +The non-functional <code>-file</code> flag has been removed. +</li> + +<li> +The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a> +subcommand will compile and link all <code>*_test.go</code> files in the package, +even when there are no <code>Test</code> functions in them. +It previously ignored such files. +</li> + +<li> +The behavior of the +<a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>build</code></a> +subcommand's +<code>-a</code> flag has been changed for non-development installations. +For installations running a released distribution, the <code>-a</code> flag will no longer +rebuild the standard library and commands, to avoid overwriting the installation's files. +</li> + +</ul> + +<h3 id="pkg">Changes to package source layout</h3> + +<p> +In the main Go source repository, the source code for the packages was kept in +the directory <code>src/pkg</code>, which made sense but differed from +other repositories, including the Go subrepositories. +In Go 1.4, the<code> pkg</code> level of the source tree is now gone, so for example +the <a href="/pkg/fmt/"><code>fmt</code></a> package's source, once kept in +directory <code>src/pkg/fmt</code>, now lives one level higher in <code>src/fmt</code>. +</p> + +<p> +<em>Updating</em>: Tools like <code>godoc</code> that discover source code +need to know about the new location. All tools and services maintained by the Go team +have been updated. +</p> + + +<h3 id="swig">SWIG</h3> + +<p> +Due to runtime changes in this release, Go 1.4 requires SWIG 3.0.3. +</p> + +<h3 id="misc">Miscellany</h3> + +<p> +The standard repository's top-level <code>misc</code> directory used to contain +Go support for editors and IDEs: plugins, initialization scripts and so on. +Maintaining these was becoming time-consuming +and needed external help because many of the editors listed were not used by +members of the core team. +It also required us to make decisions about which plugin was best for a given +editor, even for editors we do not use. +</p> + +<p> +The Go community at large is much better suited to managing this information. +In Go 1.4, therefore, this support has been removed from the repository. +Instead, there is a curated, informative list of what's available on +a <a href="//golang.org/wiki/IDEsAndTextEditorPlugins">wiki page</a>. +</p> + +<h2 id="performance">Performance</h2> + +<p> +Most programs will run about the same speed or slightly faster in 1.4 than in 1.3; +some will be slightly slower. +There are many changes, making it hard to be precise about what to expect. +</p> + +<p> +As mentioned above, much of the runtime was translated to Go from C, +which led to some reduction in heap sizes. +It also improved performance slightly because the Go compiler is better +at optimization, due to things like inlining, than the C compiler used to build +the runtime. +</p> + +<p> +The garbage collector was sped up, leading to measurable improvements for +garbage-heavy programs. +On the other hand, the new write barriers slow things down again, typically +by about the same amount but, depending on their behavior, some programs +may be somewhat slower or faster. +</p> + +<p> +Library changes that affect performance are documented below. +</p> + +<h2 id="library">Changes to the standard library</h2> + +<h3 id="new_packages">New packages</h3> + +<p> +There are no new packages in this release. +</p> + +<h3 id="major_library_changes">Major changes to the library</h3> + +<h4 id="scanner">bufio.Scanner</h4> + +<p> +The <a href="/pkg/bufio/#Scanner"><code>Scanner</code></a> type in the +<a href="/pkg/bufio/"><code>bufio</code></a> package +has had a bug fixed that may require changes to custom +<a href="/pkg/bufio/#SplitFunc"><code>split functions</code></a>. +The bug made it impossible to generate an empty token at EOF; the fix +changes the end conditions seen by the split function. +Previously, scanning stopped at EOF if there was no more data. +As of 1.4, the split function will be called once at EOF after input is exhausted, +so the split function can generate a final empty token +as the documentation already promised. +</p> + +<p> +<em>Updating</em>: Custom split functions may need to be modified to +handle empty tokens at EOF as desired. +</p> + +<h4 id="syscall">syscall</h4> + +<p> +The <a href="/pkg/syscall/"><code>syscall</code></a> package is now frozen except +for changes needed to maintain the core repository. +In particular, it will no longer be extended to support new or different system calls +that are not used by the core. +The reasons are described at length in <a href="https://golang.org/s/go1.4-syscall">a +separate document</a>. +</p> + +<p> +A new subrepository, <a href="https://golang.org/x/sys">golang.org/x/sys</a>, +has been created to serve as the location for new developments to support system +calls on all kernels. +It has a nicer structure, with three packages that each hold the implementation of +system calls for one of +<a href="http://godoc.org/golang.org/x/sys/unix">Unix</a>, +<a href="http://godoc.org/golang.org/x/sys/windows">Windows</a> and +<a href="http://godoc.org/golang.org/x/sys/plan9">Plan 9</a>. +These packages will be curated more generously, accepting all reasonable changes +that reflect kernel interfaces in those operating systems. +See the documentation and the article mentioned above for more information. +</p> + +<p> +<em>Updating</em>: Existing programs are not affected as the <code>syscall</code> +package is largely unchanged from the 1.3 release. +Future development that requires system calls not in the <code>syscall</code> package +should build on <code>golang.org/x/sys</code> instead. +</p> + +<h3 id="minor_library_changes">Minor changes to the library</h3> + +<p> +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. +</p> + +<ul> + +<li> +The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package's +<a href="/pkg/archive/zip/#Writer"><code>Writer</code></a> now supports a +<a href="/pkg/archive/zip/#Writer.Flush"><code>Flush</code></a> method. +</li> + +<li> +The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>, +<a href="/pkg/compress/gzip/"><code>compress/gzip</code></a>, +and <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a> +packages now support a <code>Reset</code> method +for the decompressors, allowing them to reuse buffers and improve performance. +The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package also has a +<a href="/pkg/compress/gzip/#Reader.Multistream"><code>Multistream</code></a> method to control support +for multistream files. +</li> + +<li> +The <a href="/pkg/crypto/"><code>crypto</code></a> package now has a +<a href="/pkg/crypto/#Signer"><code>Signer</code></a> interface, implemented by the +<code>PrivateKey</code> types in +<a href="/pkg/crypto/ecdsa"><code>crypto/ecdsa</code></a> and +<a href="/pkg/crypto/rsa"><code>crypto/rsa</code></a>. +</li> + +<li> +The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package +now supports ALPN as defined in <a href="http://tools.ietf.org/html/rfc7301">RFC 7301</a>. +</li> + +<li> +The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package +now supports programmatic selection of server certificates +through the new <a href="/pkg/crypto/tls/#Config.CertificateForName"><code>CertificateForName</code></a> function +of the <a href="/pkg/crypo/tls/#Config"><code>Config</code></a> struct. +</li> + +<li> +Also in the crypto/tls package, the server now supports +<a href="https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00">TLS_FALLBACK_SCSV</a> +to help clients detect fallback attacks. +(The Go client does not support fallback at all, so it is not vulnerable to +those attacks.) +</li> + +<li> +The <a href="/pkg/database/sql/"><code>database/sql</code></a> package can now list all registered +<a href="/pkg/database/sql/#Drivers"><code>Drivers</code></a>. +</li> + +<li> +The <a href="/pkg/debug/dwarf/"><code>debug/dwarf</code></a> package now supports +<a href="/pkg/debug/dwarf/#UnspecifiedType"><code>UnspecifiedType</code></a>s. +</li> + +<li> +In the <a href="/pkg/encoding/asn1/"><code>encoding/asn1</code></a> package, +optional elements with a default value will now only be omitted if they have that value. +</li> + +<li> +The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package no longer +quotes empty strings but does quote the end-of-data marker <code>\.</code> (backslash dot). +This is permitted by the definition of CSV and allows it to work better with Postgres. +</li> + +<li> +The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package has been rewritten to eliminate +the use of unsafe operations, allowing it to be used in environments that do not permit use of the +<a href="/pkg/unsafe/"><code>unsafe</code></a> package. +For typical uses it will be 10-30% slower, but the delta is dependent on the type of the data and +in some cases, especially involving arrays, it can be faster. +There is no functional change. +</li> + +<li> +The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package's +<a href="/pkg/encoding/xml/#Decoder"><code>Decoder</code></a> can now report its input offset. +</li> + +<li> +In the <a href="/pkg/fmt/"><code>fmt</code></a> package, +formatting of pointers to maps has changed to be consistent with that of pointers +to structs, arrays, and so on. +For instance, <code>&map[string]int{"one":</code> <code>1}</code> now prints by default as +<code>&map[one:</code> <code>1]</code> rather than as a hexadecimal pointer value. +</li> + +<li> +The <a href="/pkg/image/"><code>image</code></a> package's +<a href="/pkg/image/#Image"><code>Image</code></a> +implementations like +<a href="/pkg/image/#RGBA"><code>RGBA</code></a> and +<a href="/pkg/image/#Gray"><code>Gray</code></a> have specialized +<a href="/pkg/image/#RGBA.RGBAAt"><code>RGBAAt</code></a> and +<a href="/pkg/image/#Gray.GrayAt"><code>GrayAt</code></a> methods alongside the general +<a href="/pkg/image/#Image.At"><code>At</code></a> method. +</li> + +<li> +The <a href="/pkg/image/png/"><code>image/png</code></a> package now has an +<a href="/pkg/image/png/#Encoder"><code>Encoder</code></a> +type to control the compression level used for encoding. +</li> + +<li> +The <a href="/pkg/math/"><code>math</code></a> package now has a +<a href="/pkg/math/#Nextafter32"><code>Nextafter32</code><a/> function. +</li> + +<li> +The <a href="/pkg/net/http/"><code>net/http</code></a> package's +<a href="/pkg/net/http/#Request"><code>Request</code></a> type +has a new <a href="/pkg/net/http/#Request.BasicAuth"><code>BasicAuth</code></a> method +that returns the username and password from authenticated requests using the +HTTP Basic Authentication +Scheme. +</li> + +<li>The <a href="/pkg/net/http/"><code>net/http</code></a> package's +<a href="/pkg/net/http/#Request"><code>Transport</code></a> type +has a new <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a> hook +that allows customizing the behavior of outbound TLS connections. +</li> + +<li> +The <a href="/pkg/net/http/httputil/"><code>net/http/httputil</code></a> package's +<a href="/pkg/net/http/httputil/#ReverseProxy"><code>ReverseProxy</code></a> type +has a new field, +<a href="/pkg/net/http/#ReverseProxy.ErrorLog"><code>ErrorLog</code></a>, that +provides user control of logging. +</li> + +<li> +The <a href="/pkg/os/"><code>os</code></a> package +now implements symbolic links on the Windows operating system +through the <a href="/pkg/os/#Symlink"><code>Symlink</code></a> function. +Other operating systems already have this functionality. +There is also a new <a href="/pkg/os/#Unsetenv"><code>Unsetenv</code></a> function. +</li> + +<li> +The <a href="/pkg/reflect/"><code>reflect</code></a> package's +<a href="/pkg/reflect/#Type"><code>Type</code></a> interface +has a new method, <a href="/pkg/reflect/#type.Comparable"><code>Comparable</code></a>, +that reports whether the type implements general comparisons. +</li> + +<li> +Also in the <a href="/pkg/reflect/"><code>reflect</code></a> package, the +<a href="/pkg/reflect/#Value"><code>Value</code></a> interface is now three instead of four words +because of changes to the implementation of interfaces in the runtime. +This saves memory but has no semantic effect. +</li> + +<li> +The <a href="/pkg/runtime/"><code>runtime</code></a> package +now implements monotonic clocks on Windows, +as it already did for the other systems. +</li> + +<li> +The <a href="/pkg/runtime/"><code>runtime</code></a> package's +<a href="/pkg/runtime/#MemStats.Mallocs"><code>Mallocs</code></a> counter +now counts very small allocations that were missed in Go 1.3. +This may break tests using <a href="/pkg/runtime/#ReadMemStats"><code>ReadMemStats</code></a> +or <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a> +due to the more accurate answer. +</li> + +<li> +In the <a href="/pkg/runtime/"><code>runtime</code></a> package, +an array <a href="/pkg/runtime/#MemStats.PauseEnd"><code>PauseEnd</code></a> +has been added to the +<a href="/pkg/runtime/#MemStats"><code>MemStats</code></a> +and <a href="/pkg/runtime/#GCStats"><code>GCStats</code></a> structs. +This array is a circular buffer of times when garbage collection pauses ended. +The corresponding pause durations are already recorded in +<a href="/pkg/runtime/#MemStats.PauseNs"><code>PauseNs</code></a> +</li> + +<li> +The <a href="/pkg/runtime/race/"><code>runtime/race</code></a> package +now supports FreeBSD, which means the +<a href="/pkg/cmd/go/"><code>go</code></a> command's <code>-race</code> +flag now works on FreeBSD. +</li> + +<li> +The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package +has a new type, <a href="/pkg/sync/atomic/#Value"><code>Value</code></a>. +<code>Value</code> provides an efficient mechanism for atomic loads and +stores of values of arbitrary type. +</li> + +<li> +In the <a href="/pkg/syscall/"><code>syscall</code></a> package's +implementation on Linux, the +<a href="/pkg/syscall/#Setuid"><code>Setuid</code></a> +and <a href="/pkg/syscall/#Setgid"><code>Setgid</code></a> have been disabled +because those system calls operate on the calling thread, not the whole process, which is +different from other platforms and not the expected result. +</li> + +<li> +The <a href="/pkg/testing/"><code>testing</code></a> package +has a new facility to provide more control over running a set of tests. +If the test code contains a function +<pre> +func TestMain(m *<a href="/pkg/testing/#M"><code>testing.M</code></a>) +</pre> + +that function will be called instead of running the tests directly. +The <code>M</code> struct contains methods to access and run the tests. +</li> + +<li> +Also in the <a href="/pkg/testing/"><code>testing</code></a> package, +a new <a href="/pkg/testing/#Coverage"><code>Coverage</code></a> +function reports the current test coverage fraction, +enabling individual tests to report how much they are contributing to the +overall coverage. +</li> + +<li> +The <a href="/pkg/text/scanner/"><code>text/scanner</code></a> package's +<a href="/pkg/text/scanner/#Scanner"><code>Scanner</code></a> type +has a new function, +<a href="/pkg/text/scanner/#Scanner.IsIdentRune"><code>IsIdentRune</code></a>, +allowing one to control the definition of an identifier when scanning. +</li> + +<li> +The <a href="/pkg/text/template/"><code>text/template</code></a> package's boolean +functions <code>eq</code>, <code>lt</code>, and so on have been generalized to allow comparison +of signed and unsigned integers, simplifying their use in practice. +(Previously one could only compare values of the same signedness.) +All negative values compare less than all unsigned values. +</li> + +<li> +The <code>time</code> package now uses the standard symbol for the micro prefix, +the micro symbol (U+00B5 'ยต'), to print microsecond durations. +<a href="/pkg/time/#ParseDuration"><code>ParseDuration</code></a> still accepts <code>us</code> +but the package no longer prints microseconds as <code>us</code>. +<br> +<em>Updating</em>: Code that depends on the output format of durations +but does not use ParseDuration will need to be updated. +</li> + +</ul> |