Aggregate reference member and temporary lifetime
<p>Given this code sample, what are the rules regarding the lifetime of the temporary string being passed to <code>S</code>.</p>

<pre><code>struct S
{
    // [1] S(const std::string&amp; str) : str_{str} {}
    // [2] S(S&amp;&amp; other) : str_{std::move(other).str} {}

    const std::string&amp; str_;
};

S a{"foo"}; // direct-initialization

auto b = S{"bar"}; // copy-initialization with rvalue

std::string foobar{"foobar"};
auto c = S{foobar}; // copy-initialization with lvalue

const std::string&amp; baz = "baz";
auto d = S{baz}; // copy-initialization with lvalue-ref to temporary
</code></pre>

<p>According to the standard:</p>

<p>N4140 12.2 p5.1 (removed in N4296)</p>

<blockquote>
  <p>A temporary bound to a reference member in a constructor’s ctor-initializer (12.6.2) persists until the
  constructor exits.</p>
</blockquote>

<p>N4296 12.6.2 p8</p>

<blockquote>
  <p>A temporary expression bound to a reference member in a mem-initializer is ill-formed.</p>
</blockquote>

<p>So having a user defined constructor like <code>[1]</code> is definitively not what we want. It's even supposed to be ill-formed in the latest C++14 (or is it?) neither gcc nor clang warned about it.<br>
Does it change with direct aggregate initialization? I looks like in that case, the temporary lifetime is extended.</p>

<p>Now regarding copy-initialization, <a href="https://stackoverflow.com/questions/33379327/default-move-constructor-and-reference-members">Default move constructor and reference members</a> states that <code>[2]</code> is implicitly generated. Given the fact that the move might be elided, does the same rule apply to the implicitly generated move constructor?</p>

<p>Which of <code>a, b, c, d</code> has a valid reference?</p>