"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 }-->
    6 
    7 <h2 id="introduction">Introduction to Go 1.4</h2>
    8 
    9 <p>
   10 The latest Go release, version 1.4, arrives as scheduled six months after 1.3.
   11 </p>
   12 
   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>
   18 
   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>
   31 
   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>
   38 
   39 <h2 id="language">Changes to the language</h2>
   40 
   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>
   45 
   46 <pre>
   47 for i, v := range x {
   48     ...
   49 }
   50 </pre>
   51 
   52 <p>
   53 and
   54 </p>
   55 
   56 <pre>
   57 for i := range x {
   58     ...
   59 }
   60 </pre>
   61 
   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>
   68 
   69 <pre>
   70 for range x {
   71     ...
   72 }
   73 </pre>
   74 
   75 <p>
   76 was not syntactically permitted.
   77 </p>
   78 
   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>
   83 
   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>
   91 
   92 <h3 id="methodonpointertopointer">Method calls on **T</h3>
   93 
   94 <p>
   95 Given these declarations,
   96 </p>
   97 
   98 <pre>
   99 type T int
  100 func (T) M() {}
  101 var x **T
  102 </pre>
  103 
  104 <p>
  105 both <code>gc</code> and <code>gccgo</code> accepted the method call
  106 </p>
  107 
  108 <pre>
  109 x.M()
  110 </pre>
  111 
  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>
  119 
  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>
  124 
  125 <h2 id="os">Changes to the supported operating systems and architectures</h2>
  126 
  127 <h3 id="android">Android</h3>
  128 
  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>
  136 
  137 <h3 id="naclarm">NaCl on ARM</h3>
  138 
  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>
  145 
  146 <h3 id="plan9amd64">Plan9 on AMD64</h3>
  147 
  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>
  152 
  153 <h2 id="compatibility">Changes to the compatibility guidelines</h2>
  154 
  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>
  165 
  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>
  172   
  173 <p>
  174 <em>Updating</em>: Nothing technical has changed; this is just a clarification
  175 of the documentation.
  176 </p>
  177 
  178 
  179 <h2 id="impl">Changes to the implementations and tools</h2>
  180 
  181 <h3 id="runtime">Changes to the runtime</h3>
  182 
  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>
  191 
  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>
  199 
  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>
  207 
  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>
  212 
  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>
  221 
  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>
  232 
  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>
  242 
  243 <h3 id="asm">Assembly</h3>
  244 
  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>
  250 
  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>
  256 
  257 <pre>
  258 #include "textflag.h"
  259 </pre>
  260 
  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>
  270 
  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>
  283 
  284 <p>
  285 More information about these changes is in the <a href="/doc/asm">assembly document</a>.
  286 </p>
  287 
  288 <h3 id="gccgo">Status of gccgo</h3>
  289 
  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>
  295 
  296 <h3 id="internalpackages">Internal packages</h3>
  297 
  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>
  305 
  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>
  312 
  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>
  323 
  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>
  328 
  329 <p>
  330 Full details of the mechanism are in
  331 <a href="https://golang.org/s/go14internal">the design document</a>.
  332 </p>
  333 
  334 <h3 id="canonicalimports">Canonical import paths</h3>
  335 
  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>
  351 
  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>
  359 
  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>
  364 
  365 <pre>
  366 package pdf // import "rsc.io/pdf"
  367 </pre>
  368 
  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>
  375 
  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>
  381 
  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>
  390 
  391 <p>
  392 Further information is in
  393 <a href="https://golang.org/s/go14customimport">the design document</a>.
  394 </p>
  395 
  396 <h3 id="subrepo">Import paths for the subrepositories</h3>
  397 
  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>
  405 
  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>
  413 
  414 <h3 id="gogenerate">The go generate subcommand</h3>
  415 
  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>
  426 
  427 <p>
  428 For more information, see the 
  429 <a href="https://golang.org/s/go1.4-generate">design document</a>.
  430 </p>
  431 
  432 <h3 id="filenames">Change to file name handling</h3>
  433 
  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>
  443 
  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>
  450 
  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>
  457 
  458 <h3 id="gocmd">Other changes to the go command</h3>
  459 
  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>
  465 
  466 <ul>
  467 
  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>
  478 
  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>
  485 
  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>
  492 
  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>
  501 
  502 </ul>
  503 
  504 <h3 id="pkg">Changes to package source layout</h3>
  505 
  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>
  514 
  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>
  520 
  521 
  522 <h3 id="swig">SWIG</h3>
  523 
  524 <p>
  525 Due to runtime changes in this release, Go 1.4 requires SWIG 3.0.3.
  526 </p>
  527 
  528 <h3 id="misc">Miscellany</h3>
  529 
  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>
  539 
  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>
  546 
  547 <h2 id="performance">Performance</h2>
  548 
  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>
  554 
  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>
  562 
  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>
  570 
  571 <p>
  572 Library changes that affect performance are documented below.
  573 </p>
  574 
  575 <h2 id="library">Changes to the standard library</h2>
  576 
  577 <h3 id="new_packages">New packages</h3>
  578 
  579 <p>
  580 There are no new packages in this release.
  581 </p>
  582 
  583 <h3 id="major_library_changes">Major changes to the library</h3>
  584 
  585 <h4 id="scanner">bufio.Scanner</h4>
  586 
  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>
  599 
  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>
  604 
  605 <h4 id="syscall">syscall</h4>
  606 
  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>
  615 
  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>
  629 
  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>
  636 
  637 <h3 id="minor_library_changes">Minor changes to the library</h3>
  638 
  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>
  643 
  644 <ul>
  645 
  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>
  651 
  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>
  662 
  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>
  670 
  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>
  675 
  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>
  682 
  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>
  690 
  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>
  695 
  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>
  700 
  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>
  705 
  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>
  711 
  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>
  720 
  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>
  725 
  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>
  733 
  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>
  744 
  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>
  750 
  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>
  755 
  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>
  764 
  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>
  770 
  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>
  778 
  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>
  786 
  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>
  793 
  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>
  800 
  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>
  806 
  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>
  815 
  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>
  826 
  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>
  833 
  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>
  840 
  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>
  849 
  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>
  857 
  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>
  861 
  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>
  869 
  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>
  877 
  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>
  885 
  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>
  895 
  896 </ul>