but the rewritten program would.
(Moving `*p` ahead would be safe if the compiler can prove `*p` will not panic;
moving `*q` ahead would also require the compiler proving that no other
goroutine can access `*q`.)
</p>

<p>
Not introducing data races also means not assuming that called functions
always return or are free of synchronization operations.
For example, a compiler must not move the accesses to <code>*p</code> or <code>*q</code>

    </p>
  </dd>
</dl><!-- math/big -->

<dl id="net"><dt><a href="/pkg/net/">net</a></dt>
  <dd>
    <p><!-- https://go.dev/issue/58808 -->
      When <a href="/pkg/io#Copy"><code>io.Copy</code></a> copies
      from a <code>TCPConn</code> to a <code>UnixConn</code>,
      it will now use Linux's <code>splice(2)</code> system call if possible,

var b []byte
b = append(b, "bar"...)            // append string contents      b == []byte{'b', 'a', 'r' }
</pre>

<p>
The function <code>copy</code> copies slice elements from
a source <code>src</code> to a destination <code>dst</code> and returns the
number of elements copied.
Both arguments must have <a href="#Type_identity">identical</a> element type <code>T</code> and must be

These modes accept only 1, 2, 4, and 8 as scale factors.
</li>

</ul>

<p>
When using the compiler and assembler's
<code>-dynlink</code> or <code>-shared</code> modes,
any load or store of a fixed memory location such as a global variable
must be assumed to overwrite <code>CX</code>.
Therefore, to be safe for use with these modes,

</li>
<li>
	Both type parameters have a known type argument
	and the type arguments unify per the given matching modes.
</li>
</ul>

<p>
A single bound type parameter <code>P</code> and another type <code>T</code> unify
per the given matching modes if:
</p>

<ul>
<li>
	<code>P</code> doesn't have a known type argument.