title: moving elements of an initialization_list considered dangerous?
body: <p>Previously asked questions (<a href="https://stackoverflow.com/questions/8193102/initializer-list-and-move-semantics">1</a> and <a href="https://stackoverflow.com/questions/13957166/is-it-safe-to-move-elements-of-a-initializer-list?lq=1">2</a>) on SO seem to suggest that applying <code>std::move</code> on elements of a <code>std::initializer_list</code> may lead to UB. In fact, <code>std::initializer_list</code> iterators prevent effective move because they refer to const elements. The reason is that compilers <strong>may</strong> use static read-only memory for storing the underlying array of an initializer_list. </p>
  
  <p>I think this view is too limiting and I wanna know if experts out here agree. IMO, the following code cannot possibly use the read-only store.</p>
  
  <pre><code>void attempt_move(std::initializer_list&lt;std::string&gt; list) {
    // must use const std::string &amp;. Can't move.
  }
  int main(int argc, char *argv[])
  {
    if(argc &gt;= 4)  
      attempt_move({ argv[1], argv[2], argv[3] }); 
  }
  </code></pre>
  
  <p>The underlying <code>std::string</code> array cannot possibly live in a read-only store because, AFAIK, read-only store must be initialized before <code>main</code> and the <code>argv</code> parameters are not known at that time. In fact, the C++11 standard says: "[ Note: The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer could be so allocated. —end note ]". Seems like this is one case where the "explicit array with the same initializer" cannot be allocated read-only. So it probably has automatic storage. </p>
  
  <p>If that's true, seems like there are lost opportunities to move the string objects due to const  iterators of <code>std::initializer_list</code>. Is there a workaround?</p>