diff options
Diffstat (limited to 'doc/go1.4.html')
| -rw-r--r-- | doc/go1.4.html | 896 |
1 files changed, 0 insertions, 896 deletions
diff --git a/doc/go1.4.html b/doc/go1.4.html deleted file mode 100644 index c8f7c9c525..0000000000 --- a/doc/go1.4.html +++ /dev/null @@ -1,896 +0,0 @@ -<!--{ - "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="https://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="https://godoc.org/golang.org/x/sys/unix">Unix</a>, -<a href="https://godoc.org/golang.org/x/sys/windows">Windows</a> and -<a href="https://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="https://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/crypto/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> |