to operands that are <i>comparable</i>.
The ordering operators <code>&lt;</code>, <code>&lt;=</code>, <code>&gt;</code>, and <code>&gt;=</code>
apply to operands that are <i>ordered</i>.
These terms and the result of the comparisons are defined as follows:
</p>

<ul>
	<li>
	Boolean values are comparable.
	Two boolean values are equal if they are either both

	</li>

	<li>
	Array types are comparable if their array element types are comparable.
	Two array values are equal if their corresponding element values are equal.
	The elements are compared in ascending index order, and comparison stops
	as soon as two element values differ (or all elements have been compared).
	</li>

	<li>
	Type parameters are comparable if they are strictly comparable (see below).
	</li>

Any value of comparable type may be canonicalized with the new
`Make[T]` function, which produces a reference to a canonical copy of
the value in the form of a `Handle[T]`.
Two `Handle[T]` are equal if and only if the values used to produce the
handles are equal, allowing programs to deduplicate values and reduce
their memory footprint.
Comparing two `Handle[T]` values is efficient, reducing down to a simple

Package builtin provides documentation for Go's predeclared identifiers.
The items documented here are not actually in package builtin
but their descriptions here allow godoc to present documentation
for the language's special identifiers.
*/
package builtin

import "cmp"

// bool is the set of boolean values, true and false.
type bool bool

// true and false are the two untyped boolean values.
const (
	true  = 0 == 0 // Untyped bool.

### Timer changes

Go 1.23 makes two significant changes to the implementation of
[time.Timer] and [time.Ticker].

First, `Timer`s and `Ticker`s that are no longer referred to by the program
become eligible for garbage collection immediately, even if their
`Stop` methods have not been called.
Earlier versions of Go did not collect unstopped `Timer`s until after
they had fired and never collected unstopped `Ticker`s.

# Release Notes

The `initial` and `next` subdirectories of this directory are for release notes.

## For developers

Release notes should be added to `next` by editing existing files or creating
new files. **Do not add RELNOTE=yes comments in CLs.** Instead, add a file to
the CL (or ask the author to do so).

At the end of the development cycle, the files will be merged by being
concatenated in sorted order by pathname. Files in the directory matching the

On Windows, the mode bits reported by [Lstat] and [Stat] for
reparse points changed. Mount points no longer have [ModeSymlink] set,
and reparse points that are not symlinks, Unix sockets, or dedup files
now always have [ModeIrregular] set.
This behavior is controlled by the `winsymlink` setting.
For Go 1.23, it defaults to `winsymlink=1`.

Programs with more than one `//go:debug` line for a given setting
are also treated as invalid.
(Older toolchains ignore `//go:debug` directives entirely.)

The defaults that will be compiled into a main package
are reported by the command:

{{raw `
	go list -f '{{.DefaultGODEBUG}}' my/main/package
`}}

Only differences from the base Go toolchain defaults are reported.

Vendoring in std and cmd
========================

The Go command maintains copies of external packages needed by the
standard library in the src/vendor and src/cmd/vendor directories.

There are two modules, std and cmd, defined in src/go.mod and
src/cmd/go.mod. When a package outside std or cmd is imported
by a package inside std or cmd, the import path is interpreted
as if it had a "vendor/" prefix. For example, within "crypto/tls",

The [SliceAt(typ Type, p unsafe.Pointer, len int)] function
returns a Value representing a slice whose underlying array starts