title: Copy-initialization vs direct-initialization has changed?
body: <p>I learned, long ago, that copy initialization creates a temporary which is then used to initialize the destination, though the latter copy constructor is optimized out; but the compiler still pretends to use it, checking for existence and allowed access.</p>
  
  <p>I noticed Herb Sutter mention, in <a href="https://herbsutter.com/gotw/" rel="nofollow noreferrer">updated GOTW posts</a>, that this is no longer true when <code>auto</code> is used.</p>
  
  <p>Specifically, Herb (writing in 2013) still states the familiar rules in general:</p>
  
  <blockquote>
    <p>If <code>x</code> is of some other type, conceptually the compiler first implicitly converts x to a temporary widget object… Note that I said “conceptually” a few times above. That’s because practically compilers are allowed to, and routinely do, optimize away the temporary  — from <a href="https://herbsutter.com/2013/05/09/gotw-1-solution/" rel="nofollow noreferrer">GOTW #1</a></p>
  </blockquote>
  
  <p>He later notes that when <code>auto</code> is used (in <code>auto w = x;</code>) that only a single copy constructor is called because there is no way that <code>x</code> needs to be converted first.</p>
  
  <p>In the case of a function returning an iterator (so it’s an rvalue):</p>
  
  <blockquote>
    <p>After all, as we saw in GotW #1, usually that extra <code>=</code> means the two-step “convert to a temporary then copy/move” of copy-initialization—but recall <strong>that doesn’t apply when using <code>auto</code> like this</strong>. … presto! there cannot be any need for a conversion and we directly construct <code>i</code>.  —<a href="https://herbsutter.com/2013/05/13/gotw-2-solution-temporary-objects/" rel="nofollow noreferrer">GOTW #2</a> (emphasis mine)</p>
  </blockquote>
  
  <p>If the type returned from the function was exactly the same type as the variable being initialized with copy initialization, the rule would be that the temporary gets optimized out but it still checks access on the copy constructor.  Herb is saying that this is not the case with <code>auto</code>, but direct initialization is used.</p>
  
  <p>There are other examples where he seems to be saying (though not with rigorous precision) that when using <code>auto</code> you no longer have the compiler pretend to use the copy constructor.</p>
  
  <p>What’s going on?  Has the rule changed?  Is this some additional feature of <code>auto</code> that all the presentations have missed mentioning?</p>