if err := b.UnreadByte(); err == nil {
		t.Fatal("UnreadByte after ReadByte at EOF: got no error")
	}

	// check not at EOF
	b.WriteString("abcdefghijklmnopqrstuvwxyz")

	// after unsuccessful read
	if n, err := b.Read(nil); n != 0 || err != nil {
		t.Fatalf("Read(nil) = %d,%v; want 0,nil", n, err)
	}
	if err := b.UnreadByte(); err == nil {
		t.Fatal("UnreadByte after Read(nil): got no error")
	}

</pre>

<p>
the variable <code>a</code> will be initialized after <code>b</code> but
whether <code>x</code> is initialized before <code>b</code>, between
<code>b</code> and <code>a</code>, or after <code>a</code>, and
thus also the moment at which <code>sideEffect()</code> is called (before
or after <code>x</code> is initialized) is not specified.
</p>

<p>

Earlier versions of Go did not collect unstopped `Timer`s until after
they had fired and never collected unstopped `Ticker`s.

Second, the timer channel associated with a `Timer` or `Ticker` is
now unbuffered, with capacity 0.
The main effect of this change is that Go now guarantees
that for any call to a `Reset` or `Stop` method, no stale values
prepared before that call will be sent or received after the call.

Files in this repo's `api/next` directory must have corresponding files in
`doc/next/*stdlib/*minor`.
The files should be in the subdirectory for the package with the new
API, and should be named after the issue number of the API proposal.
For example, if the directory `6-stdlib/99-minor` is present,
then an `api/next` file with the line

    pkg net/http, function F #12345

// The close built-in function closes a channel, which must be either
// bidirectional or send-only. It should be executed only by the sender,
// never the receiver, and has the effect of shutting down the channel after
// the last sent value is received. After the last value has been received
// from a closed channel c, any receive from c will succeed without
// blocking, returning the zero value for the channel element. The form
//
//	x, ok := <-c
//

</pre>

<p>
the variable <code>a</code> will be initialized after <code>b</code> but
whether <code>x</code> is initialized before <code>b</code>, between
<code>b</code> and <code>a</code>, or after <code>a</code>, and
thus also the moment at which <code>sideEffect()</code> is called (before
or after <code>x</code> is initialized) is not specified.
</p>

<p>