1
0
mirror of https://github.com/golang/go synced 2024-11-23 03:30:02 -07:00
go/doc/go1.21.html

149 lines
4.7 KiB
HTML
Raw Normal View History

<!--{
"Title": "Go 1.21 Release Notes",
"Path": "/doc/go1.21"
}-->
<!--
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.21</h2>
<p>
<strong>
Go 1.21 is not yet released. These are work-in-progress
release notes. Go 1.21 is expected to be released in August 2023.
</strong>
</p>
<h2 id="language">Changes to the language</h2>
<p>
TODO: complete this section
</p>
<h2 id="ports">Ports</h2>
<h3 id="wasip1">WebAssembly System Interface</h3>
<p><!-- https://go.dev/issue/58141 -->
Go 1.21 adds an experimental port to the <a href="https://wasi.dev/">
WebAssembly System Interface (WASI)</a>, Preview 1
(<code>GOOS=wasip1</code>, <code>GOARCH=wasm</code>).
</p>
<p>
As a result of the addition of the new <code>GOOS</code> value
"<code>wasip1</code>", Go files named <code>*_wasip1.go</code>
will now be <a href="/pkg/go/build/#hdr-Build_Constraints">ignored
by Go tools</a> except when that GOOS value is being used. If you
have existing filenames matching that pattern, you will need to
rename them.
</p>
<h2 id="tools">Tools</h2>
<h3 id="go-command">Go command</h3>
<p><-- https://go.dev/issue/58099, CL 474236 -->
The <code>-pgo</code> build flag now defaults to <code>-pgo=auto</code>,
and the restriction of specifying a single main package on the command
line is now removed. If a file named <code>default.pgo</code> is present
in the main package's directory, the <code>go</code> command will use
it to enable profile-guided optimization for building the corresponding
program.
</p>
<h2 id="runtime">Runtime</h2>
<p>
TODO: complete this section, or delete if not needed
</p>
<p><!-- https://go.dev/issue/7181 -->
When printing very deep stacks, the runtime now prints the first 50
(innermost) frames followed by the bottom 50 (outermost) frames,
rather than just printing the first 100 frames. This makes it easier
to see how deeply recursive stacks started, and is especially
valuable for debugging stack overflows.
</p>
<h2 id="compiler">Compiler</h2>
<p>
TODO: complete this section, or delete if not needed
</p>
<h2 id="linker">Linker</h2>
<p>
TODO: complete this section, or delete if not needed
</p>
<h2 id="library">Core library</h2>
<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.
There are also various performance improvements, not enumerated here.
</p>
<p>
TODO: complete this section
</p>
sync: implement OnceFunc, OnceValue, and OnceValues This adds the three functions from #56102 to the sync package. These provide a convenient API for the most common uses of sync.Once. The performance of these is comparable to direct use of sync.Once: $ go test -run ^$ -bench OnceFunc\|OnceVal -count 20 | benchstat -row .name -col /v goos: linux goarch: amd64 pkg: sync cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz │ Once │ Global │ Local │ │ sec/op │ sec/op vs base │ sec/op vs base │ OnceFunc 1.3500n ± 6% 2.7030n ± 1% +100.22% (p=0.000 n=20) 0.3935n ± 0% -70.86% (p=0.000 n=20) OnceValue 1.3155n ± 0% 2.7460n ± 1% +108.74% (p=0.000 n=20) 0.5478n ± 1% -58.35% (p=0.000 n=20) The "Once" column represents the baseline of how code would typically express these patterns using sync.Once. "Global" binds the closure returned by OnceFunc/OnceValue to global, which is how I expect these to be used most of the time. Currently, this defeats some inlining opportunities, which roughly doubles the cost over sync.Once; however, it's still *extremely* fast. Finally, "Local" binds the returned closure to a local variable. This unlocks several levels of inlining and represents pretty much the best possible case for these APIs, but is also unlikely to happen in practice. In principle the compiler could recognize that the global in the "Global" case is initialized in place and never mutated and do the same optimizations it does in the "Local" case, but it currently does not. Fixes #56102 Change-Id: If7355eccd7c8de7288d89a4282ff15ab1469e420 Reviewed-on: https://go-review.googlesource.com/c/go/+/451356 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Caleb Spare <cespare@gmail.com> Auto-Submit: Austin Clements <austin@google.com>
2022-11-17 14:00:57 -07:00
<dl id="context"><dt><a href="/pkg/context/">context</a></dt>
<dd>
<p><!-- https://go.dev/issue/40221, CL 479918 -->
The new <a href="/pkg/context/#WithoutCancel"><code>WithoutCancel</code></a>
function returns a copy of a context that is not canceled when the original
context is canceled.
</p>
<p><!-- https://go.dev/issue/56661, CL 449318 -->
The new <a href="/pkg/context/#WithDeadlineCause"><code>WithDeadlineCause</code></a>
and <a href="/pkg/context/#WithTimeoutCause"><code>WithTimeoutCause</code></a>
functions provide a way to set a context cancellation cause when a deadline or
timer expires. The cause may be retrieved with the
<a href="/pkg/context/#Cause"><code>Cause</code></a> function.
</p>
<p><!-- https://go.dev/issue/57928, CL 482695 -->
The new <a href="/pkg/context/#AfterFunc"><code>AfterFunc</code></a>
function registers a function to run after a context has been cancelled.
</p>
</dd>
</dl>
<dl id="reflect"><dt><a href="/pkg/reflect/">reflect</a></dt>
<dd>
<p><!-- CL 408826, CL 413474 -->
In Go 1.21, <a href="/pkg/reflect/#ValueOf"><code>ValueOf</code></a>
no longer forces its argument to be allocated on the heap, allowing
a <code>Value</code>'s content to be allocated on the stack. Most
operations on a <code>Value</code> also allow the underlying value
to be stack allocated.
</p>
</dd>
</dl>
sync: implement OnceFunc, OnceValue, and OnceValues This adds the three functions from #56102 to the sync package. These provide a convenient API for the most common uses of sync.Once. The performance of these is comparable to direct use of sync.Once: $ go test -run ^$ -bench OnceFunc\|OnceVal -count 20 | benchstat -row .name -col /v goos: linux goarch: amd64 pkg: sync cpu: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz │ Once │ Global │ Local │ │ sec/op │ sec/op vs base │ sec/op vs base │ OnceFunc 1.3500n ± 6% 2.7030n ± 1% +100.22% (p=0.000 n=20) 0.3935n ± 0% -70.86% (p=0.000 n=20) OnceValue 1.3155n ± 0% 2.7460n ± 1% +108.74% (p=0.000 n=20) 0.5478n ± 1% -58.35% (p=0.000 n=20) The "Once" column represents the baseline of how code would typically express these patterns using sync.Once. "Global" binds the closure returned by OnceFunc/OnceValue to global, which is how I expect these to be used most of the time. Currently, this defeats some inlining opportunities, which roughly doubles the cost over sync.Once; however, it's still *extremely* fast. Finally, "Local" binds the returned closure to a local variable. This unlocks several levels of inlining and represents pretty much the best possible case for these APIs, but is also unlikely to happen in practice. In principle the compiler could recognize that the global in the "Global" case is initialized in place and never mutated and do the same optimizations it does in the "Local" case, but it currently does not. Fixes #56102 Change-Id: If7355eccd7c8de7288d89a4282ff15ab1469e420 Reviewed-on: https://go-review.googlesource.com/c/go/+/451356 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Andrew Gerrand <adg@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Caleb Spare <cespare@gmail.com> Auto-Submit: Austin Clements <austin@google.com>
2022-11-17 14:00:57 -07:00
<dl id="sync"><dt><a href="/pkg/sync/">sync</a></dt>
<dd>
<p><!-- https://go.dev/issue/56102, CL 451356 -->
The new <a href="/pkg/sync/#OnceFunc"><code>OnceFunc</code></a>,
<a href="/pkg/sync/#OnceValue"><code>OnceValue</code></a>, and
<a href="/pkg/sync/#OnceValues"><code>OnceValues</code></a>
functions capture a common use of <a href="/pkg/sync/#Once">Once</a> to
lazily initialize a value on first use.
</p>
</dd>
</dl>