<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 23 September 2014 18:59, David Krauss <span dir="ltr">&lt;<a href="mailto:david_work@me.com" target="_blank">david_work@me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 2014–09–24, at 9:39 AM, Richard Smith &lt;<a href="mailto:richardsmith@google.com">richardsmith@google.com</a>&gt; wrote:<br>
<br>
&gt; I think we simply want to say that if an id-expression naming a reference appears in its own initializer, the program is ill-formed unless the id-expression is an unevaluated operand or subexpression thereof.<br>
&gt;<br>
&gt;<br>
&gt; I don&#39;t think ill-formed, NDR is a good approach here: this is easy to diagnose in the &quot;obvious&quot; cases, and no different from other similar (non-reference) cases that lead to UB in the &quot;non-obvious&quot; cases, so I think we should make the obvious case ill-formed and leave the other cases as UB.<br>
<br>
</span>That’s only QOI. No need for standardization.<br>
<span class=""><br>
&gt; Also, ill-formed, NDR implies that *all* executions of the program have undefined behavior (if the compiler accepts it, which it&#39;s permitted to), even if they don&#39;t actually execute the UB. For instance,<br>
<br>
</span>This was my intent.</blockquote><div><br></div><div>Then I&#39;m strongly opposed. It does not seem acceptable to silently change existing valid and well-defined code into having undefined behavior. I&#39;m sure I&#39;m not the only one who&#39;ll feel this way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If a compiler with stronger static analysis finds any circular reference initialization, it should be allowed to balk because the program is nonsense before it ever runs.</blockquote><div><br></div><div>It should be allowed to warn, and that is the status quo; if people want errors, compilers commonly have a feature to turn their warnings into errors. We don&#39;t need a language change to allow that. But allowing one compiler to reject (in its conforming mode) where another compiler accepts, for a program that runs without undefined behavior, is not reasonable. That&#39;s a disaster for portability and predictability.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A reference is supposed to have a referent. Otherwise, it may need to implement an effort to pull a result out of thin air before issuing a mere warning.</blockquote><div><br></div><div>If a compiler happens to stumble on undefined behavior when emitting code, it doesn&#39;t need to put in an effort to do anything in particular. Any code it emits is fine.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; I don&#39;t think that odr-use is a good approach here, since odr-use means something else (and in particular, you can name a reference in an evaluated context without odr-using it, if it&#39;s initialized by a constant expression). That is, I want this to be ill-formed:<br>
&gt;<br>
&gt;  const int &amp;r = true ? 0 : r;<br>
&gt;<br>
&gt; ... even though the mention of &#39;r&#39; here happens to not be an odr-use.<br>
<br>
</span>Use in a potentially evaluated context sounds better than ODR-use, but the compiler doesn’t know that whole initializer is a constant expression at the time it’s processing the self-reference.</blockquote><div><br></div><div>Exactly; that&#39;s one reason why I think we shouldn&#39;t rely on odr-use here.</div></div></div></div>