In Go, when will a variable become unreachable?
<p>Go 1.7 beta 1 was released this morning, here is <a href="https://tip.golang.org/doc/go1.7" rel="noreferrer">the release notes draft of Go 1.7</a>. A new function <code>KeepAlive</code> was added to the package <code>runtime</code>. <a href="https://tip.golang.org/pkg/runtime/#KeepAlive" rel="noreferrer">The doc of <code>runtime.KeepAlive</code></a> has given an example:</p>

<pre><code>type File struct { d int }
d, err := syscall.Open("/file/path", syscall.O_RDONLY, 0)
// ... do something if err != nil ...
p := &amp;FILE{d}
runtime.SetFinalizer(p, func(p *File) { syscall.Close(p.d) })
var buf [10]byte
n, err := syscall.Read(p.d, buf[:])
// Ensure p is not finalized until Read returns.
runtime.KeepAlive(p)
// No more uses of p after this point.
</code></pre>

<p><a href="https://tip.golang.org/pkg/runtime/#SetFinalizer" rel="noreferrer">The doc of <code>runtime.SetFinalizer</code></a> has also given an explanation about <code>runtime.KeepAlive</code>:</p>

<blockquote>
  <p>For example, if p points to a struct that contains a file descriptor
  d, and p has a finalizer that closes that file descriptor, and if the
  last use of p in a function is a call to syscall.Write(p.d, buf,
  size), then p may be unreachable as soon as the program enters
  syscall.Write. The finalizer may run at that moment, closing p.d,
  causing syscall.Write to fail because it is writing to a closed file
  descriptor (or, worse, to an entirely different file descriptor opened
  by a different goroutine). To avoid this problem, call
  runtime.KeepAlive(p) after the call to syscall.Write.</p>
</blockquote>

<p>What confused me is that the variable <code>p</code> has not left its life scope yet, why will it be unreachable? Does that mean that a variable will be unreachable if only there is no use of it in the following code, no matter whether it is in its life scope?</p>