go/doc/go1.16.html

<!--{
	"Title": "Go 1.16 Release Notes",
	"Path":  "/doc/go1.16"
}-->

<!--
NOTE: In this document and others in this directory, the convention is to
set fixed-width phrases with non-fixed-width spaces, as in
<code>hello</code> <code>world</code>.
Do not send CLs removing the interior tags from such phrases.
-->

<style>
  main ul li { margin: 0.5em 0; }
</style>

<h2 id="introduction">DRAFT RELEASE NOTES — Introduction to Go 1.16</h2>

<p>
  <strong>
    Go 1.16 is not yet released. These are work-in-progress
    release notes. Go 1.16 is expected to be released in February 2021.
  </strong>
</p>

<h2 id="language">Changes to the language</h2>

<p>
  TODO
</p>

<h2 id="ports">Ports</h2>

<p>
  TODO
</p>

<h2 id="tools">Tools</h2>

<p>
  TODO
</p>

<h3 id="go-command">Go command</h3>

<h4 id="modules">Modules</h4>

<p><!-- golang.org/issue/40276 -->
  <code>go</code> <code>install</code> now accepts arguments with
  version suffixes (for example, <code>go</code> <code>install</code>
  <code>example.com/cmd@v1.0.0</code>). This causes <code>go</code>
  <code>install</code> to build and install packages in module-aware mode,
  ignoring the <code>go.mod</code> file in the current directory or any parent
  directory, if there is one. This is useful for installing executables without
  affecting the dependencies of the main module.<br>
  TODO: write and link to section in golang.org/ref/mod<br>
  TODO: write and link to blog post
</p>

<p><!-- golang.org/issue/24031 -->
  <code>retract</code> directives may now be used in a <code>go.mod</code> file
  to indicate that certain published versions of the module should not be used
  by other modules. A module author may retract a version after a severe problem
  is discovered or if the version was published unintentionally.<br>
  TODO: write and link to section in golang.org/ref/mod<br>
  TODO: write and link to tutorial or blog post
</p>

<p><!-- golang.org/issue/26603 -->
  The <code>go</code> <code>mod</code> <code>vendor</code>
  and <code>go</code> <code>mod</code> <code>tidy</code> subcommands now accept
  the <code>-e</code> flag, which instructs them to proceed despite errors in
  resolving missing packages.
</p>

<h4 id="go-test"><code>go</code> <code>test</code></h4>

<p><!-- golang.org/issue/29062 -->
  When using <code>go</code> <code>test</code>, a test that
  calls <code>os.Exit(0)</code> during execution of a test function
  will now be considered to fail.
  This will help catch cases in which a test calls code that calls
  <code>os.Exit(0)</code> and thereby stops running all future tests.
  If a <code>TestMain</code> function calls <code>os.Exit(0)</code>
  that is still considered to be a passing test.
</p>

<p><!-- golang.org/issue/37519 -->
  The <code>go</code> <code>get</code> <code>-insecure</code> flag is
  deprecated and will be removed in a future version. The <code>GOINSECURE</code>
  environment variable should be used instead, since it provides control
  over which modules may be retrieved using an insecure scheme. Unlike the
  <code>-insecure</code> flag, <code>GOINSECURE</code> does not disable module
  sum validation using the checksum database. The <code>GOPRIVATE</code> or
  <code>GONOSUMDB</code> environment variables may be used instead.
</p>

<h4 id="all-pattern">The <code>all</code> pattern</h4>

<p><!-- golang.org/cl/240623 -->
  When the main module's <code>go.mod</code> file
  declares <code>go</code> <code>1.16</code> or higher, the <code>all</code>
  package pattern now matches only those packages that are transitively imported
  by a package or test found in the main module. (Packages imported by <em>tests
  of</em> packages imported by the main module are no longer included.) This is
  the same set of packages retained
  by <code>go</code> <code>mod</code> <code>vendor</code> since Go 1.11.
</p>

<h3 id="cgo">Cgo</h3>

<p> <!-- CL 252378 -->
  The <a href="/cmd/cgo">cgo</a> tool will no longer try to translate
  C struct bitfields into Go struct fields, even if their size can be
  represented in Go. The order in which C bitfields appear in memory
  is implementation dependent, so in some cases the cgo tool produced
  results that were silently incorrect.
</p>

<p>
  TODO
</p>

<h2 id="runtime">Runtime</h2>

<p>
  TODO
</p>

<h2 id="compiler">Compiler</h2>

<p>
  TODO
</p>

<h2 id="linker">Linker</h2>

<p>
  This release includes additional improvements to the Go linker,
  reducing linker resource usage (both time and memory) and improving
  code robustness/maintainability. These changes form the second half
  of a two-release project to
  <a href="https://golang.org/s/better-linker">modernize the Go
  linker</a>.
</p>

<p>
  The linker changes in 1.16 extend the 1.15 improvements to all
  supported architecture/OS combinations (the 1.15 performance improvements
  were primarily focused on <code>ELF</code>-based OSes and
  <code>amd64</code> architectures).  For a representative set of
  large Go programs, linking is 20-35% faster than 1.15 and requires
  5-15% less memory on average for <code>linux/amd64</code>, with larger
  improvements for other architectures and OSes.
</p>

<p>
  TODO: update with final numbers later in the release.
</p>

<h2 id="library">Core library</h2>

<p>
  TODO
</p>

<h3 id="net"><a href="/pkg/net/">net</a></h3>

<p><!-- CL 250357 -->
  The case of I/O on a closed network connection, or I/O on a network
  connection that is closed before any of the I/O completes, can now
  be detected using the new <a href="/pkg/net/#ErrClosed">ErrClosed</a> error.
  A typical use would be <code>errors.Is(err, net.ErrClosed)</code>.
  In earlier releases the only way to reliably detect this case was to
  match the string returned by the <code>Error</code> method
  with <code>"use of closed network connection"</code>.
</p>


<h3 id="text/template/parse"><a href="/pkg/text/template/parse/">text/template/parse</a></h3>

<p><!-- CL 229398, golang.org/issue/34652 -->
  A new <a href="/pkg/text/template/parse/#CommentNode"><code>CommentNode</code></a>
  was added to the parse tree. The <a href="/pkg/text/template/parse/#Mode"><code>Mode</code></a>
  field in the <code>parse.Tree</code> enables access to it.
</p>
<!-- text/template/parse -->

<h3 id="unicode"><a href="/pkg/unicode/">unicode</a></h3>

<p><!-- CL 248765 -->
  The <a href="/pkg/unicode/"><code>unicode</code></a> package and associated
  support throughout the system has been upgraded from Unicode 12.0.0 to
  <a href="https://www.unicode.org/versions/Unicode13.0.0/">Unicode 13.0.0</a>,
  which adds 5,930 new characters, including four new scripts, and 55 new emoji.
  Unicode 13.0.0 also designates plane 3 (U+30000-U+3FFFF) as the tertiary
  ideographic plane.
</p>

<h3 id="minor_library_changes">Minor changes to the library</h3>

<p>
  As always, there are various minor changes and updates to the library,
  made with the Go 1 <a href="/doc/go1compat">promise of compatibility</a>
  in mind.
</p>

<p>
  TODO
</p>

<dl id="net/http"><dt><a href="/pkg/net/http/">net/http</a></dt>
  <dd>
    <p><!-- CL 233637 -->
      In the <a href="/pkg/net/http/"><code>net/http</code></a> package, the
      behavior of <a href="/pkg/net/http/#StripPrefix"><code>StripPrefix</code></a>
      has been changed to strip the prefix from the request URL's
      <code>RawPath</code> field in addition to its <code>Path</code> field.
      In past releases, only the <code>Path</code> field was trimmed, and so if the
      request URL contained any escaped characters the URL would be modified to
      have mismatched <code>Path</code> and <code>RawPath</code> fields.
      In Go 1.16, <code>StripPrefix</code> trims both fields.
      If there are escaped characters in the prefix part of the request URL the
      handler serves a 404 instead of its previous behavior of invoking the
      underlying handler with a mismatched <code>Path</code>/<code>RawPath</code> pair.
    </p>

    <p><!-- CL 252497 -->
     The <a href="/pkg/net/http/"><code>net/http</code></a> package now rejects HTTP range requests
     of the form <code>"Range": "bytes=--N"</code> where <code>"-N"</code> is a negative suffix length, for
     example <code>"Range": "bytes=--2"</code>. It now replies with a <code>416 "Range Not Satisfiable"</code> response.
    </p>
  </dd>
</dl><!-- net/http -->