<p dir="auto">We only permit <code class="notranslate">&amp;mut</code> pointees to be mutated if the <code class="notranslate">&amp;mut</code> is in a unique location (i.e., another <code class="notranslate">&amp;mut</code>, a local variable, etc). Based on this, it is safe to conclude that the memory referenced by an <code class="notranslate">&amp;mut</code> pointer found in an <em>aliasable</em> location is frozen. But the borrow checker considers such memory to be unsafe for use. This is overly conservative and prevents important compositional patterns.</p>
<p dir="auto">In particular, I should be able to define a type <code class="notranslate">BorrowedMap</code> that looks like this:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="struct BorrowedMap&lt;'m,K,V&gt; {
    map: &amp;'m mut HashMap&lt;K,V&gt;
}"><pre class="notranslate"><code class="notranslate">struct BorrowedMap&lt;'m,K,V&gt; {
    map: &amp;'m mut HashMap&lt;K,V&gt;
}
</code></pre></div>
<p dir="auto">and now I should be able to implement the <code class="notranslate">Map&lt;K,V&gt;</code> trait for <code class="notranslate">BorrowedMap</code>:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="impl&lt;'m,K,V&gt; Map&lt;K,V&gt; for BorrowedMap&lt;'m,K,V&gt; {
    fn insert(&amp;mut self, key: K, value: V) { self.map.insert(key, value); }
    fn find&lt;'a&gt;(&amp;'a self, key: &amp;K) -&gt; Option&lt;'a V&gt; {
        self.map.find(key) // ERROR
    }
}"><pre class="notranslate"><code class="notranslate">impl&lt;'m,K,V&gt; Map&lt;K,V&gt; for BorrowedMap&lt;'m,K,V&gt; {
    fn insert(&amp;mut self, key: K, value: V) { self.map.insert(key, value); }
    fn find&lt;'a&gt;(&amp;'a self, key: &amp;K) -&gt; Option&lt;'a V&gt; {
        self.map.find(key) // ERROR
    }
}
</code></pre></div>
<p dir="auto">However I can't because I get an error at the marked line. This is because <code class="notranslate">self.map</code> is an <code class="notranslate">&amp;mut</code> found inside of an aliasable location (<code class="notranslate">self</code>) and hence it cannot be considered frozen. But why not? Nobody can mutate it, after all.</p>
<p dir="auto">Note that the maximum lifetime of a freeze would be <code class="notranslate">'a</code> (which is sufficient for this case).</p>
<p dir="auto">Nominating.</p>
<p dir="auto">Now that the swap operator has been removed, I do not believe the<br>
restriction against mutating <code class="notranslate">LV</code> is needed, and in fact it prevents<br>
some useful patterns. For example, the following function will<br>
fail to compile:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="       fn mut_shift_ref&lt;'a,T&gt;(x: &amp;mut &amp;'a mut [T]) -&gt; &amp;'a mut T {
           // `mut_split` will restrict mutation against *x:
           let (head, tail) = (*x).mut_split(1);

           // Hence mutating `*x` yields an error here:
           *x = tail;
           &amp;mut head[0]
       }"><pre class="notranslate"><code class="notranslate">       fn mut_shift_ref&lt;'a,T&gt;(x: &amp;mut &amp;'a mut [T]) -&gt; &amp;'a mut T {
           // `mut_split` will restrict mutation against *x:
           let (head, tail) = (*x).mut_split(1);

           // Hence mutating `*x` yields an error here:
           *x = tail;
           &amp;mut head[0]
       }
</code></pre></div>
<p dir="auto">Note that this function -- which adjusts the slice <code class="notranslate">*x</code> in place so<br>
that it no longer contains the head element and then returns a<br>
pointer to that element separately -- is perfectly valid. It is<br>
currently implemented using unsafe code. I believe that now that<br>
the swap operator is removed from the language, we could liberalize<br>
the rules and make this function be accepted normally. The idea<br>
would be to have the assignment to <code class="notranslate">*x</code> kill the loans of <code class="notranslate">*x</code> and<br>
its subpaths -- after all, those subpaths are no longer accessible<br>
through <code class="notranslate">*x</code>, since it has been overwritten with a new value. Thus<br>
those subpaths are only accessible through prior existing borrows<br>
of <code class="notranslate">*x</code>, if any. The danger of the <em>swap</em> operator was that it<br>
allowed <code class="notranslate">*x</code> to be mutated without making the subpaths of <code class="notranslate">*x</code><br>
inaccessible: worse, they became accessible through a new path (I<br>
suppose that we could have supported a swap operator, too, if needed, by moving the loans over to the new path).</p>