On 2014–09–24, at 9:39 AM, Richard Smith <richardsmith_at_[hidden]> wrote:

> 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.
>
>
> I don't think ill-formed, NDR is a good approach here: this is easy to diagnose in the "obvious" cases, and no different from other similar (non-reference) cases that lead to UB in the "non-obvious" cases, so I think we should make the obvious case ill-formed and leave the other cases as UB.

That’s only QOI. No need for standardization.

> Also, ill-formed, NDR implies that *all* executions of the program have undefined behavior (if the compiler accepts it, which it's permitted to), even if they don't actually execute the UB. For instance,

This was my intent. 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. 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.

> I don'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's initialized by a constant expression). That is, I want this to be ill-formed:
>
> const int &r = true ? 0 : r;
>
> ... even though the mention of 'r' here happens to not be an odr-use.

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.