Why is implicit conversion from const to non-const allowed? : <p>Why does C++ allow the following code to compile?</p>

<pre><code>std::unordered_map&lt;std::string, int&gt; m;
// ...
for (const std::pair&lt;std::string, int&gt;&amp; p: m)
{
    // ...
}
</code></pre>

<p>According to <a href="http://shop.oreilly.com/product/0636920033707.do" rel="noreferrer">Scott Meyers' <em>Effective Modern C++</em></a> (p. 40-41):</p>

<blockquote>
  <p>[...] the key part of a <code>std::unordered_map</code> is <code>const</code>, so the type of <code>std::pair</code> in the hash table (which is what a <code>std::unordered_map</code> is) isn’t <code>std::pair&lt;std::string, int&gt;</code>, it's <code>std::pair &lt;const std::string, int&gt;</code>. But that's not the type declared for the variable <code>p</code> in the loop above. As a result, compilers will strive to find a way to convert <code>std::pair&lt;const std::string, int&gt;</code> objects (i.e., what’s in the hash table) to <code>std::pair&lt;std::string, int&gt;</code> objects (the declared type for <code>p</code>). They’ll succeed by creating a temporary object of the type that <code>p</code> wants to bind to by copying each object in <code>m</code>, then binding the reference p to that temporary object. At the end of each loop iteration, the temporary object will be destroyed. If you wrote this loop, you'd likely be surprised by this behavior, because you'd almost certainly intend to simply bind the reference <code>p</code> to each element in <code>m</code>.</p>
</blockquote>

<p>What is the benefit of allowing this implicit conversion? Is there some common use case where the developer would expect / prefer this implicit conversion (rather than getting a compiler error)?</p>
