"Fossies" - the Fresh Open Source Software Archive

Member "go/doc/go1.4.html" (9 Sep 2020, 33535 Bytes) of package /windows/misc/go1.14.9.windows-386.zip:

As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) HTML source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 <!--{
    2     "Title": "Go 1.4 Release Notes",
    3     "Path":  "/doc/go1.4",
    4     "Template": true
    5 }-->
    7 <h2 id="introduction">Introduction to Go 1.4</h2>
    9 <p>
   10 The latest Go release, version 1.4, arrives as scheduled six months after 1.3.
   11 </p>
   13 <p>
   14 It contains only one tiny language change,
   15 in the form of a backwards-compatible simple variant of <code>for</code>-<code>range</code> loop,
   16 and a possibly breaking change to the compiler involving methods on pointers-to-pointers.
   17 </p>
   19 <p>
   20 The release focuses primarily on implementation work, improving the garbage collector
   21 and preparing the ground for a fully concurrent collector to be rolled out in the
   22 next few releases.
   23 Stacks are now contiguous, reallocated when necessary rather than linking on new
   24 "segments";
   25 this release therefore eliminates the notorious "hot stack split" problem.
   26 There are some new tools available including support in the <code>go</code> command
   27 for build-time source code generation.
   28 The release also adds support for ARM processors on Android and Native Client (NaCl)
   29 and for AMD64 on Plan 9.
   30 </p>
   32 <p>
   33 As always, Go 1.4 keeps the <a href="/doc/go1compat.html">promise
   34 of compatibility</a>,
   35 and almost everything 
   36 will continue to compile and run without change when moved to 1.4.
   37 </p>
   39 <h2 id="language">Changes to the language</h2>
   41 <h3 id="forrange">For-range loops</h3>
   42 <p>
   43 Up until Go 1.3, <code>for</code>-<code>range</code> loop had two forms
   44 </p>
   46 <pre>
   47 for i, v := range x {
   48     ...
   49 }
   50 </pre>
   52 <p>
   53 and
   54 </p>
   56 <pre>
   57 for i := range x {
   58     ...
   59 }
   60 </pre>
   62 <p>
   63 If one was not interested in the loop values, only the iteration itself, it was still
   64 necessary to mention a variable (probably the <a href="/ref/spec#Blank_identifier">blank identifier</a>, as in
   65 <code>for</code> <code>_</code> <code>=</code> <code>range</code> <code>x</code>), because
   66 the form
   67 </p>
   69 <pre>
   70 for range x {
   71     ...
   72 }
   73 </pre>
   75 <p>
   76 was not syntactically permitted.
   77 </p>
   79 <p>
   80 This situation seemed awkward, so as of Go 1.4 the variable-free form is now legal.
   81 The pattern arises rarely but the code can be cleaner when it does.
   82 </p>
   84 <p>
   85 <em>Updating</em>: The change is strictly backwards compatible to existing Go
   86 programs, but tools that analyze Go parse trees may need to be modified to accept
   87 this new form as the
   88 <code>Key</code> field of <a href="/pkg/go/ast/#RangeStmt"><code>RangeStmt</code></a>
   89 may now be <code>nil</code>.
   90 </p>
   92 <h3 id="methodonpointertopointer">Method calls on **T</h3>
   94 <p>
   95 Given these declarations,
   96 </p>
   98 <pre>
   99 type T int
  100 func (T) M() {}
  101 var x **T
  102 </pre>
  104 <p>
  105 both <code>gc</code> and <code>gccgo</code> accepted the method call
  106 </p>
  108 <pre>
  109 x.M()
  110 </pre>
  112 <p>
  113 which is a double dereference of the pointer-to-pointer <code>x</code>.
  114 The Go specification allows a single dereference to be inserted automatically,
  115 but not two, so this call is erroneous according to the language definition.
  116 It has therefore been disallowed in Go 1.4, which is a breaking change,
  117 although very few programs will be affected.
  118 </p>
  120 <p>
  121 <em>Updating</em>: Code that depends on the old, erroneous behavior will no longer
  122 compile but is easy to fix by adding an explicit dereference.
  123 </p>
  125 <h2 id="os">Changes to the supported operating systems and architectures</h2>
  127 <h3 id="android">Android</h3>
  129 <p>
  130 Go 1.4 can build binaries for ARM processors running the Android operating system.
  131 It can also build a <code>.so</code> library that can be loaded by an Android application
  132 using the supporting packages in the <a href="https://golang.org/x/mobile">mobile</a> subrepository.
  133 A brief description of the plans for this experimental port are available
  134 <a href="https://golang.org/s/go14android">here</a>.
  135 </p>
  137 <h3 id="naclarm">NaCl on ARM</h3>
  139 <p>
  140 The previous release introduced Native Client (NaCl) support for the 32-bit x86
  141 (<code>GOARCH=386</code>)
  142 and 64-bit x86 using 32-bit pointers (GOARCH=amd64p32).
  143 The 1.4 release adds NaCl support for ARM (GOARCH=arm).
  144 </p>
  146 <h3 id="plan9amd64">Plan9 on AMD64</h3>
  148 <p>
  149 This release adds support for the Plan 9 operating system on AMD64 processors,
  150 provided the kernel supports the <code>nsec</code> system call and uses 4K pages.
  151 </p>
  153 <h2 id="compatibility">Changes to the compatibility guidelines</h2>
  155 <p>
  156 The <a href="/pkg/unsafe/"><code>unsafe</code></a> package allows one
  157 to defeat Go's type system by exploiting internal details of the implementation
  158 or machine representation of data.
  159 It was never explicitly specified what use of <code>unsafe</code> meant
  160 with respect to compatibility as specified in the
  161 <a href="go1compat.html">Go compatibility guidelines</a>.
  162 The answer, of course, is that we can make no promise of compatibility
  163 for code that does unsafe things.
  164 </p>
  166 <p>
  167 We have clarified this situation in the documentation included in the release.
  168 The <a href="go1compat.html">Go compatibility guidelines</a> and the
  169 docs for the <a href="/pkg/unsafe/"><code>unsafe</code></a> package
  170 are now explicit that unsafe code is not guaranteed to remain compatible.
  171 </p>
  173 <p>
  174 <em>Updating</em>: Nothing technical has changed; this is just a clarification
  175 of the documentation.
  176 </p>
  179 <h2 id="impl">Changes to the implementations and tools</h2>
  181 <h3 id="runtime">Changes to the runtime</h3>
  183 <p>
  184 Prior to Go 1.4, the runtime (garbage collector, concurrency support, interface management,
  185 maps, slices, strings, ...) was mostly written in C, with some assembler support.
  186 In 1.4, much of the code has been translated to Go so that the garbage collector can scan
  187 the stacks of programs in the runtime and get accurate information about what variables
  188 are active.
  189 This change was large but should have no semantic effect on programs.
  190 </p>
  192 <p>
  193 This rewrite allows the garbage collector in 1.4 to be fully precise,
  194 meaning that it is aware of the location of all active pointers in the program.
  195 This means the heap will be smaller as there will be no false positives keeping non-pointers alive.
  196 Other related changes also reduce the heap size, which is smaller by 10%-30% overall
  197 relative to the previous release.
  198 </p>
  200 <p>
  201 A consequence is that stacks are no longer segmented, eliminating the "hot split" problem.
  202 When a stack limit is reached, a new, larger stack is allocated, all active frames for
  203 the goroutine are copied there, and any pointers into the stack are updated.
  204 Performance can be noticeably better in some cases and is always more predictable.
  205 Details are available in <a href="https://golang.org/s/contigstacks">the design document</a>.
  206 </p>
  208 <p>
  209 The use of contiguous stacks means that stacks can start smaller without triggering performance issues,
  210 so the default starting size for a goroutine's stack in 1.4 has been reduced from 8192 bytes to 2048 bytes.
  211 </p>
  213 <p>
  214 As preparation for the concurrent garbage collector scheduled for the 1.5 release,
  215 writes to pointer values in the heap are now done by a function call,
  216 called a write barrier, rather than directly from the function updating the value.
  217 In this next release, this will permit the garbage collector to mediate writes to the heap while it is running.
  218 This change has no semantic effect on programs in 1.4, but was
  219 included in the release to test the compiler and the resulting performance.
  220 </p>
  222 <p>
  223 The implementation of interface values has been modified.
  224 In earlier releases, the interface contained a word that was either a pointer or a one-word
  225 scalar value, depending on the type of the concrete object stored.
  226 This implementation was problematical for the garbage collector,
  227 so as of 1.4 interface values always hold a pointer.
  228 In running programs, most interface values were pointers anyway,
  229 so the effect is minimal, but programs that store integers (for example) in
  230 interfaces will see more allocations.
  231 </p>
  233 <p>
  234 As of Go 1.3, the runtime crashes if it finds a memory word that should contain
  235 a valid pointer but instead contains an obviously invalid pointer (for example, the value 3).
  236 Programs that store integers in pointer values may run afoul of this check and crash.
  237 In Go 1.4, setting the <a href="/pkg/runtime/"><code>GODEBUG</code></a> variable
  238 <code>invalidptr=0</code> disables
  239 the crash as a workaround, but we cannot guarantee that future releases will be
  240 able to avoid the crash; the correct fix is to rewrite code not to alias integers and pointers.
  241 </p>
  243 <h3 id="asm">Assembly</h3>
  245 <p>
  246 The language accepted by the assemblers <code>cmd/5a</code>, <code>cmd/6a</code>
  247 and <code>cmd/8a</code> has had several changes,
  248 mostly to make it easier to deliver type information to the runtime.
  249 </p>
  251 <p>
  252 First, the <code>textflag.h</code> file that defines flags for <code>TEXT</code> directives
  253 has been copied from the linker source directory to a standard location so it can be
  254 included with the simple directive
  255 </p>
  257 <pre>
  258 #include "textflag.h"
  259 </pre>
  261 <p>
  262 The more important changes are in how assembler source can define the necessary
  263 type information.
  264 For most programs it will suffice to move data
  265 definitions (<code>DATA</code> and <code>GLOBL</code> directives)
  266 out of assembly into Go files
  267 and to write a Go declaration for each assembly function.
  268 The <a href="/doc/asm#runtime">assembly document</a> describes what to do.
  269 </p>
  271 <p>
  272 <em>Updating</em>:
  273 Assembly files that include <code>textflag.h</code> from its old
  274 location will still work, but should be updated.
  275 For the type information, most assembly routines will need no change,
  276 but all should be examined.
  277 Assembly source files that define data,
  278 functions with non-empty stack frames, or functions that return pointers
  279 need particular attention.
  280 A description of the necessary (but simple) changes
  281 is in the <a href="/doc/asm#runtime">assembly document</a>.
  282 </p>
  284 <p>
  285 More information about these changes is in the <a href="/doc/asm">assembly document</a>.
  286 </p>
  288 <h3 id="gccgo">Status of gccgo</h3>
  290 <p>
  291 The release schedules for the GCC and Go projects do not coincide.
  292 GCC release 4.9 contains the Go 1.2 version of gccgo.
  293 The next release, GCC 5, will likely have the Go 1.4 version of gccgo.
  294 </p>
  296 <h3 id="internalpackages">Internal packages</h3>
  298 <p>
  299 Go's package system makes it easy to structure programs into components with clean boundaries,
  300 but there are only two forms of access: local (unexported) and global (exported).
  301 Sometimes one wishes to have components that are not exported,
  302 for instance to avoid acquiring clients of interfaces to code that is part of a public repository
  303 but not intended for use outside the program to which it belongs.
  304 </p>
  306 <p>
  307 The Go language does not have the power to enforce this distinction, but as of Go 1.4 the
  308 <a href="/cmd/go/"><code>go</code></a> command introduces
  309 a mechanism to define "internal" packages that may not be imported by packages outside
  310 the source subtree in which they reside.
  311 </p>
  313 <p>
  314 To create such a package, place it in a directory named <code>internal</code> or in a subdirectory of a directory
  315 named internal.
  316 When the <code>go</code> command sees an import of a package with <code>internal</code> in its path,
  317 it verifies that the package doing the import
  318 is within the tree rooted at the parent of the <code>internal</code> directory.
  319 For example, a package <code>.../a/b/c/internal/d/e/f</code>
  320 can be imported only by code in the directory tree rooted at <code>.../a/b/c</code>.
  321 It cannot be imported by code in <code>.../a/b/g</code> or in any other repository.
  322 </p>
  324 <p>
  325 For Go 1.4, the internal package mechanism is enforced for the main Go repository;
  326 from 1.5 and onward it will be enforced for any repository.
  327 </p>
  329 <p>
  330 Full details of the mechanism are in
  331 <a href="https://golang.org/s/go14internal">the design document</a>.
  332 </p>
  334 <h3 id="canonicalimports">Canonical import paths</h3>
  336 <p>
  337 Code often lives in repositories hosted by public services such as <code>github.com</code>,
  338 meaning that the import paths for packages begin with the name of the hosting service,
  339 <code>github.com/rsc/pdf</code> for example.
  340 One can use
  341 <a href="/cmd/go/#hdr-Remote_import_paths">an existing mechanism</a>
  342 to provide a "custom" or "vanity" import path such as
  343 <code>rsc.io/pdf</code>, but
  344 that creates two valid import paths for the package.
  345 That is a problem: one may inadvertently import the package through the two
  346 distinct paths in a single program, which is wasteful;
  347 miss an update to a package because the path being used is not recognized to be
  348 out of date;
  349 or break clients using the old path by moving the package to a different hosting service.
  350 </p>
  352 <p>
  353 Go 1.4 introduces an annotation for package clauses in Go source that identify a canonical
  354 import path for the package.
  355 If an import is attempted using a path that is not canonical,
  356 the <a href="/cmd/go/"><code>go</code></a> command
  357 will refuse to compile the importing package.
  358 </p>
  360 <p>
  361 The syntax is simple: put an identifying comment on the package line.
  362 For our example, the package clause would read:
  363 </p>
  365 <pre>
  366 package pdf // import "rsc.io/pdf"
  367 </pre>
  369 <p>
  370 With this in place,
  371 the <code>go</code> command will
  372 refuse to compile a package that imports <code>github.com/rsc/pdf</code>, 
  373 ensuring that the code can be moved without breaking users.
  374 </p>
  376 <p>
  377 The check is at build time, not download time, so if <code>go</code> <code>get</code>
  378 fails because of this check, the mis-imported package has been copied to the local machine
  379 and should be removed manually.
  380 </p>
  382 <p>
  383 To complement this new feature, a check has been added at update time to verify
  384 that the local package's remote repository matches that of its custom import.
  385 The <code>go</code> <code>get</code> <code>-u</code> command will fail to
  386 update a package if its remote repository has changed since it was first
  387 downloaded.
  388 The new <code>-f</code> flag overrides this check.
  389 </p>
  391 <p>
  392 Further information is in
  393 <a href="https://golang.org/s/go14customimport">the design document</a>.
  394 </p>
  396 <h3 id="subrepo">Import paths for the subrepositories</h3>
  398 <p>
  399 The Go project subrepositories (<code>code.google.com/p/go.tools</code> and so on)
  400 are now available under custom import paths replacing <code>code.google.com/p/go.</code> with <code>golang.org/x/</code>,
  401 as in <code>golang.org/x/tools</code>.
  402 We will add canonical import comments to the code around June 1, 2015,
  403 at which point Go 1.4 and later will stop accepting the old <code>code.google.com</code> paths.
  404 </p>
  406 <p>
  407 <em>Updating</em>: All code that imports from subrepositories should change
  408 to use the new <code>golang.org</code> paths.
  409 Go 1.0 and later can resolve and import the new paths, so updating will not break
  410 compatibility with older releases.
  411 Code that has not updated will stop compiling with Go 1.4 around June 1, 2015.
  412 </p>
  414 <h3 id="gogenerate">The go generate subcommand</h3>
  416 <p>
  417 The <a href="/cmd/go/"><code>go</code></a> command has a new subcommand,
  418 <a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go generate</code></a>,
  419 to automate the running of tools to generate source code before compilation.
  420 For example, it can be used to run the <a href="/cmd/yacc"><code>yacc</code></a>
  421 compiler-compiler on a <code>.y</code> file to produce the Go source file implementing the grammar,
  422 or to automate the generation of <code>String</code> methods for typed constants using the new
  423 <a href="https://godoc.org/golang.org/x/tools/cmd/stringer">stringer</a>
  424 tool in the <code>golang.org/x/tools</code> subrepository.
  425 </p>
  427 <p>
  428 For more information, see the 
  429 <a href="https://golang.org/s/go1.4-generate">design document</a>.
  430 </p>
  432 <h3 id="filenames">Change to file name handling</h3>
  434 <p>
  435 Build constraints, also known as build tags, control compilation by including or excluding files
  436 (see the documentation <a href="/pkg/go/build/"><code>/go/build</code></a>).
  437 Compilation can also be controlled by the name of the file itself by "tagging" the file with
  438 a suffix (before the <code>.go</code> or <code>.s</code> extension) with an underscore
  439 and the name of the architecture or operating system.
  440 For instance, the file <code>gopher_arm.go</code> will only be compiled if the target
  441 processor is an ARM.
  442 </p>
  444 <p>
  445 Before Go 1.4, a file called just <code>arm.go</code> was similarly tagged, but this behavior
  446 can break sources when new architectures are added, causing files to suddenly become tagged.
  447 In 1.4, therefore, a file will be tagged in this manner only if the tag (architecture or operating
  448 system name) is preceded by an underscore.
  449 </p>
  451 <p>
  452 <em>Updating</em>: Packages that depend on the old behavior will no longer compile correctly.
  453 Files with names like <code>windows.go</code> or <code>amd64.go</code> should either
  454 have explicit build tags added to the source or be renamed to something like
  455 <code>os_windows.go</code> or <code>support_amd64.go</code>.
  456 </p>
  458 <h3 id="gocmd">Other changes to the go command</h3>
  460 <p>
  461 There were a number of minor changes to the
  462 <a href="/cmd/go/"><code>cmd/go</code></a>
  463 command worth noting.
  464 </p>
  466 <ul>
  468 <li>
  469 Unless <a href="/cmd/cgo/"><code>cgo</code></a> is being used to build the package,
  470 the <code>go</code> command now refuses to compile C source files,
  471 since the relevant C compilers
  472 (<a href="/cmd/6c/"><code>6c</code></a> etc.)
  473 are intended to be removed from the installation in some future release.
  474 (They are used today only to build part of the runtime.)
  475 It is difficult to use them correctly in any case, so any extant uses are likely incorrect,
  476 so we have disabled them.
  477 </li>
  479 <li>
  480 The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
  481 subcommand has a new flag, <code>-o</code>, to set the name of the resulting binary,
  482 corresponding to the same flag in other subcommands.
  483 The non-functional <code>-file</code> flag has been removed.
  484 </li>
  486 <li>
  487 The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
  488 subcommand will compile and link all <code>*_test.go</code> files in the package,
  489 even when there are no <code>Test</code> functions in them. 
  490 It previously ignored such files.
  491 </li>
  493 <li>
  494 The behavior of the
  495 <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>build</code></a>
  496 subcommand's
  497 <code>-a</code> flag has been changed for non-development installations.
  498 For installations running a released distribution, the <code>-a</code> flag will no longer
  499 rebuild the standard library and commands, to avoid overwriting the installation's files.
  500 </li>
  502 </ul>
  504 <h3 id="pkg">Changes to package source layout</h3>
  506 <p>
  507 In the main Go source repository, the source code for the packages was kept in
  508 the directory <code>src/pkg</code>, which made sense but differed from
  509 other repositories, including the Go subrepositories.
  510 In Go 1.4, the<code> pkg</code> level of the source tree is now gone, so for example
  511 the <a href="/pkg/fmt/"><code>fmt</code></a> package's source, once kept in
  512 directory <code>src/pkg/fmt</code>, now lives one level higher in <code>src/fmt</code>.
  513 </p>
  515 <p>
  516 <em>Updating</em>: Tools like <code>godoc</code> that discover source code
  517 need to know about the new location. All tools and services maintained by the Go team
  518 have been updated.
  519 </p>
  522 <h3 id="swig">SWIG</h3>
  524 <p>
  525 Due to runtime changes in this release, Go 1.4 requires SWIG 3.0.3.
  526 </p>
  528 <h3 id="misc">Miscellany</h3>
  530 <p>
  531 The standard repository's top-level <code>misc</code> directory used to contain
  532 Go support for editors and IDEs: plugins, initialization scripts and so on.
  533 Maintaining these was becoming time-consuming
  534 and needed external help because many of the editors listed were not used by
  535 members of the core team.
  536 It also required us to make decisions about which plugin was best for a given
  537 editor, even for editors we do not use.
  538 </p>
  540 <p>
  541 The Go community at large is much better suited to managing this information.
  542 In Go 1.4, therefore, this support has been removed from the repository.
  543 Instead, there is a curated, informative list of what's available on
  544 a <a href="//golang.org/wiki/IDEsAndTextEditorPlugins">wiki page</a>.
  545 </p>
  547 <h2 id="performance">Performance</h2>
  549 <p>
  550 Most programs will run about the same speed or slightly faster in 1.4 than in 1.3;
  551 some will be slightly slower.
  552 There are many changes, making it hard to be precise about what to expect.
  553 </p>
  555 <p>
  556 As mentioned above, much of the runtime was translated to Go from C,
  557 which led to some reduction in heap sizes.
  558 It also improved performance slightly because the Go compiler is better
  559 at optimization, due to things like inlining, than the C compiler used to build
  560 the runtime.
  561 </p>
  563 <p>
  564 The garbage collector was sped up, leading to measurable improvements for
  565 garbage-heavy programs.
  566 On the other hand, the new write barriers slow things down again, typically
  567 by about the same amount but, depending on their behavior, some programs
  568 may be somewhat slower or faster.
  569 </p>
  571 <p>
  572 Library changes that affect performance are documented below.
  573 </p>
  575 <h2 id="library">Changes to the standard library</h2>
  577 <h3 id="new_packages">New packages</h3>
  579 <p>
  580 There are no new packages in this release.
  581 </p>
  583 <h3 id="major_library_changes">Major changes to the library</h3>
  585 <h4 id="scanner">bufio.Scanner</h4>
  587 <p>
  588 The <a href="/pkg/bufio/#Scanner"><code>Scanner</code></a> type in the
  589 <a href="/pkg/bufio/"><code>bufio</code></a> package
  590 has had a bug fixed that may require changes to custom
  591 <a href="/pkg/bufio/#SplitFunc"><code>split functions</code></a>. 
  592 The bug made it impossible to generate an empty token at EOF; the fix
  593 changes the end conditions seen by the split function.
  594 Previously, scanning stopped at EOF if there was no more data.
  595 As of 1.4, the split function will be called once at EOF after input is exhausted,
  596 so the split function can generate a final empty token
  597 as the documentation already promised.
  598 </p>
  600 <p>
  601 <em>Updating</em>: Custom split functions may need to be modified to
  602 handle empty tokens at EOF as desired.
  603 </p>
  605 <h4 id="syscall">syscall</h4>
  607 <p>
  608 The <a href="/pkg/syscall/"><code>syscall</code></a> package is now frozen except
  609 for changes needed to maintain the core repository.
  610 In particular, it will no longer be extended to support new or different system calls
  611 that are not used by the core.
  612 The reasons are described at length in <a href="https://golang.org/s/go1.4-syscall">a
  613 separate document</a>.
  614 </p>
  616 <p>
  617 A new subrepository, <a href="https://golang.org/x/sys">golang.org/x/sys</a>,
  618 has been created to serve as the location for new developments to support system
  619 calls on all kernels.
  620 It has a nicer structure, with three packages that each hold the implementation of
  621 system calls for one of
  622 <a href="https://godoc.org/golang.org/x/sys/unix">Unix</a>,
  623 <a href="https://godoc.org/golang.org/x/sys/windows">Windows</a> and
  624 <a href="https://godoc.org/golang.org/x/sys/plan9">Plan 9</a>.
  625 These packages will be curated more generously, accepting all reasonable changes
  626 that reflect kernel interfaces in those operating systems.
  627 See the documentation and the article mentioned above for more information.
  628 </p>
  630 <p>
  631 <em>Updating</em>: Existing programs are not affected as the <code>syscall</code>
  632 package is largely unchanged from the 1.3 release.
  633 Future development that requires system calls not in the <code>syscall</code> package
  634 should build on <code>golang.org/x/sys</code> instead.
  635 </p>
  637 <h3 id="minor_library_changes">Minor changes to the library</h3>
  639 <p>
  640 The following list summarizes a number of minor changes to the library, mostly additions.
  641 See the relevant package documentation for more information about each change.
  642 </p>
  644 <ul>
  646 <li>
  647 The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package's
  648 <a href="/pkg/archive/zip/#Writer"><code>Writer</code></a> now supports a
  649 <a href="/pkg/archive/zip/#Writer.Flush"><code>Flush</code></a> method.
  650 </li>
  652 <li>
  653 The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>,
  654 <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a>,
  655 and <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a>
  656 packages now support a <code>Reset</code> method
  657 for the decompressors, allowing them to reuse buffers and improve performance.
  658 The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package also has a
  659 <a href="/pkg/compress/gzip/#Reader.Multistream"><code>Multistream</code></a> method to control support
  660 for multistream files.
  661 </li>
  663 <li>
  664 The <a href="/pkg/crypto/"><code>crypto</code></a> package now has a
  665 <a href="/pkg/crypto/#Signer"><code>Signer</code></a> interface, implemented by the
  666 <code>PrivateKey</code> types in
  667 <a href="/pkg/crypto/ecdsa"><code>crypto/ecdsa</code></a> and
  668 <a href="/pkg/crypto/rsa"><code>crypto/rsa</code></a>.
  669 </li>
  671 <li>
  672 The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
  673 now supports ALPN as defined in <a href="https://tools.ietf.org/html/rfc7301">RFC 7301</a>.
  674 </li>
  676 <li>
  677 The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
  678 now supports programmatic selection of server certificates
  679 through the new <a href="/pkg/crypto/tls/#Config.CertificateForName"><code>CertificateForName</code></a> function
  680 of the <a href="/pkg/crypto/tls/#Config"><code>Config</code></a> struct.
  681 </li>
  683 <li>
  684 Also in the crypto/tls package, the server now supports 
  685 <a href="https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00">TLS_FALLBACK_SCSV</a>
  686 to help clients detect fallback attacks.
  687 (The Go client does not support fallback at all, so it is not vulnerable to
  688 those attacks.)
  689 </li>
  691 <li>
  692 The <a href="/pkg/database/sql/"><code>database/sql</code></a> package can now list all registered
  693 <a href="/pkg/database/sql/#Drivers"><code>Drivers</code></a>.
  694 </li>
  696 <li>
  697 The <a href="/pkg/debug/dwarf/"><code>debug/dwarf</code></a> package now supports
  698 <a href="/pkg/debug/dwarf/#UnspecifiedType"><code>UnspecifiedType</code></a>s.
  699 </li>
  701 <li>
  702 In the <a href="/pkg/encoding/asn1/"><code>encoding/asn1</code></a> package,
  703 optional elements with a default value will now only be omitted if they have that value.
  704 </li>
  706 <li>
  707 The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package no longer
  708 quotes empty strings but does quote the end-of-data marker <code>\.</code> (backslash dot).
  709 This is permitted by the definition of CSV and allows it to work better with Postgres.
  710 </li>
  712 <li>
  713 The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package has been rewritten to eliminate
  714 the use of unsafe operations, allowing it to be used in environments that do not permit use of the
  715 <a href="/pkg/unsafe/"><code>unsafe</code></a> package.
  716 For typical uses it will be 10-30% slower, but the delta is dependent on the type of the data and
  717 in some cases, especially involving arrays, it can be faster.
  718 There is no functional change.
  719 </li>
  721 <li>
  722 The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package's
  723 <a href="/pkg/encoding/xml/#Decoder"><code>Decoder</code></a> can now report its input offset.
  724 </li>
  726 <li>
  727 In the <a href="/pkg/fmt/"><code>fmt</code></a> package,
  728 formatting of pointers to maps has changed to be consistent with that of pointers
  729 to structs, arrays, and so on.
  730 For instance, <code>&amp;map[string]int{"one":</code> <code>1}</code> now prints by default as
  731 <code>&amp;map[one:</code> <code>1]</code> rather than as a hexadecimal pointer value.
  732 </li>
  734 <li>
  735 The <a href="/pkg/image/"><code>image</code></a> package's
  736 <a href="/pkg/image/#Image"><code>Image</code></a>
  737 implementations like
  738 <a href="/pkg/image/#RGBA"><code>RGBA</code></a> and
  739 <a href="/pkg/image/#Gray"><code>Gray</code></a> have specialized
  740 <a href="/pkg/image/#RGBA.RGBAAt"><code>RGBAAt</code></a> and
  741 <a href="/pkg/image/#Gray.GrayAt"><code>GrayAt</code></a> methods alongside the general
  742 <a href="/pkg/image/#Image.At"><code>At</code></a> method.
  743 </li>
  745 <li>
  746 The <a href="/pkg/image/png/"><code>image/png</code></a> package now has an
  747 <a href="/pkg/image/png/#Encoder"><code>Encoder</code></a>
  748 type to control the compression level used for encoding.
  749 </li>
  751 <li>
  752 The <a href="/pkg/math/"><code>math</code></a> package now has a
  753 <a href="/pkg/math/#Nextafter32"><code>Nextafter32</code><a/> function.
  754 </li>
  756 <li>
  757 The <a href="/pkg/net/http/"><code>net/http</code></a> package's
  758 <a href="/pkg/net/http/#Request"><code>Request</code></a> type
  759 has a new <a href="/pkg/net/http/#Request.BasicAuth"><code>BasicAuth</code></a> method
  760 that returns the username and password from authenticated requests using the
  761 HTTP Basic Authentication
  762 Scheme.
  763 </li>
  765 <li>The <a href="/pkg/net/http/"><code>net/http</code></a> package's
  766 <a href="/pkg/net/http/#Request"><code>Transport</code></a> type
  767 has a new <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a> hook
  768 that allows customizing the behavior of outbound TLS connections.
  769 </li>
  771 <li>
  772 The <a href="/pkg/net/http/httputil/"><code>net/http/httputil</code></a> package's
  773 <a href="/pkg/net/http/httputil/#ReverseProxy"><code>ReverseProxy</code></a> type
  774 has a new field,
  775 <a href="/pkg/net/http/#ReverseProxy.ErrorLog"><code>ErrorLog</code></a>, that
  776 provides user control of logging.
  777 </li>
  779 <li>
  780 The <a href="/pkg/os/"><code>os</code></a> package
  781 now implements symbolic links on the Windows operating system
  782 through the <a href="/pkg/os/#Symlink"><code>Symlink</code></a> function.
  783 Other operating systems already have this functionality.
  784 There is also a new <a href="/pkg/os/#Unsetenv"><code>Unsetenv</code></a> function.
  785 </li>
  787 <li>
  788 The <a href="/pkg/reflect/"><code>reflect</code></a> package's
  789 <a href="/pkg/reflect/#Type"><code>Type</code></a> interface
  790 has a new method, <a href="/pkg/reflect/#type.Comparable"><code>Comparable</code></a>,
  791 that reports whether the type implements general comparisons.
  792 </li>
  794 <li>
  795 Also in the <a href="/pkg/reflect/"><code>reflect</code></a> package, the
  796 <a href="/pkg/reflect/#Value"><code>Value</code></a> interface is now three instead of four words
  797 because of changes to the implementation of interfaces in the runtime.
  798 This saves memory but has no semantic effect.
  799 </li>
  801 <li>
  802 The <a href="/pkg/runtime/"><code>runtime</code></a> package
  803 now implements monotonic clocks on Windows,
  804 as it already did for the other systems.
  805 </li>
  807 <li>
  808 The <a href="/pkg/runtime/"><code>runtime</code></a> package's
  809 <a href="/pkg/runtime/#MemStats.Mallocs"><code>Mallocs</code></a> counter
  810 now counts very small allocations that were missed in Go 1.3.
  811 This may break tests using <a href="/pkg/runtime/#ReadMemStats"><code>ReadMemStats</code></a>
  812 or <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
  813 due to the more accurate answer.
  814 </li>
  816 <li>
  817 In the <a href="/pkg/runtime/"><code>runtime</code></a> package,
  818 an array <a href="/pkg/runtime/#MemStats.PauseEnd"><code>PauseEnd</code></a>
  819 has been added to the
  820 <a href="/pkg/runtime/#MemStats"><code>MemStats</code></a>
  821 and <a href="/pkg/runtime/#GCStats"><code>GCStats</code></a> structs.
  822 This array is a circular buffer of times when garbage collection pauses ended.
  823 The corresponding pause durations are already recorded in
  824 <a href="/pkg/runtime/#MemStats.PauseNs"><code>PauseNs</code></a>
  825 </li>
  827 <li>
  828 The <a href="/pkg/runtime/race/"><code>runtime/race</code></a> package
  829 now supports FreeBSD, which means the
  830 <a href="/pkg/cmd/go/"><code>go</code></a> command's <code>-race</code>
  831 flag now works on FreeBSD.
  832 </li>
  834 <li>
  835 The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
  836 has a new type, <a href="/pkg/sync/atomic/#Value"><code>Value</code></a>.
  837 <code>Value</code> provides an efficient mechanism for atomic loads and
  838 stores of values of arbitrary type.
  839 </li>
  841 <li>
  842 In the <a href="/pkg/syscall/"><code>syscall</code></a> package's
  843 implementation on Linux, the
  844 <a href="/pkg/syscall/#Setuid"><code>Setuid</code></a>
  845 and <a href="/pkg/syscall/#Setgid"><code>Setgid</code></a> have been disabled
  846 because those system calls operate on the calling thread, not the whole process, which is
  847 different from other platforms and not the expected result.
  848 </li>
  850 <li>
  851 The <a href="/pkg/testing/"><code>testing</code></a> package
  852 has a new facility to provide more control over running a set of tests.
  853 If the test code contains a function
  854 <pre>
  855 func TestMain(m *<a href="/pkg/testing/#M"><code>testing.M</code></a>) 
  856 </pre>
  858 that function will be called instead of running the tests directly.
  859 The <code>M</code> struct contains methods to access and run the tests.
  860 </li>
  862 <li>
  863 Also in the <a href="/pkg/testing/"><code>testing</code></a> package,
  864 a new <a href="/pkg/testing/#Coverage"><code>Coverage</code></a>
  865 function reports the current test coverage fraction,
  866 enabling individual tests to report how much they are contributing to the
  867 overall coverage.
  868 </li>
  870 <li>
  871 The <a href="/pkg/text/scanner/"><code>text/scanner</code></a> package's
  872 <a href="/pkg/text/scanner/#Scanner"><code>Scanner</code></a> type
  873 has a new function,
  874 <a href="/pkg/text/scanner/#Scanner.IsIdentRune"><code>IsIdentRune</code></a>,
  875 allowing one to control the definition of an identifier when scanning.
  876 </li>
  878 <li>
  879 The <a href="/pkg/text/template/"><code>text/template</code></a> package's boolean
  880 functions <code>eq</code>, <code>lt</code>, and so on have been generalized to allow comparison
  881 of signed and unsigned integers, simplifying their use in practice.
  882 (Previously one could only compare values of the same signedness.)
  883 All negative values compare less than all unsigned values.
  884 </li>
  886 <li>
  887 The <code>time</code> package now uses the standard symbol for the micro prefix,
  888 the micro symbol (U+00B5 'ยต'), to print microsecond durations.
  889 <a href="/pkg/time/#ParseDuration"><code>ParseDuration</code></a> still accepts <code>us</code>
  890 but the package no longer prints microseconds as <code>us</code>.
  891 <br>
  892 <em>Updating</em>: Code that depends on the output format of durations
  893 but does not use ParseDuration will need to be updated.
  894 </li>
  896 </ul>