2

In this answer in SO the OP says:

Per basic.def.odr/2, the set of potential results of A::a[0] is empty, so A::a is odr-used by this expression.

Doesn't A::a[0] satisfy the second bullet point in [basic.def.odr]/2? If this were the case, wouldn't A::a be a potential result of A::a[0]?

And then, we would conclude that A::a is not odr-used by A::a[0] in the initialization int a = A::a[0];, by [basic.def.odr]/3, which is exactly the opposite of what the OP said in his answer.

What am I missing?

Edit When I mention above the second bullet point in [basic.def.odr]/2, I'm referring to the draft N4618. This bullet point was not present in the draft N3936 referred to by the OP. So it seems to me, that according to N3936 A::a was odr-used by A::a[0], but it is not by N4618. Am I correct?

Community
  • 1
  • 1
João Afonso
  • 1,934
  • 13
  • 19
  • It took me a long time to grok the odr section and I still have to think about it a lot, I have gone back to this answer many times. His comments [starting here elaborates](http://stackoverflow.com/questions/23428684/is-a-constexpr-array-necessarily-odr-used-when-subscripted/23436665#comment35966241_23436665). My answer [here](http://stackoverflow.com/a/28446388/1708801) may help a little. – Shafik Yaghmour Mar 10 '17 at 18:40
  • For "the second bullet point", I read "If `e` is a class member access expression [...]", but "class member access" is limited to the `.` and `->` operators, neither of which you've got there. Do you mean some other bullet point? Have the items perhaps been re-ordered at some point? Otherwise I'm having trouble understanding the question. –  Mar 10 '17 at 18:45
  • @ShafikYaghmour As far as I can understand the second bullet point in [basic.def.odr]/2 says that `A::a` is potential result of `A::a[0]`. – João Afonso Mar 10 '17 at 18:47
  • @hvd When I say the second bullet point I'm referring to the latest draft N4618. But now I can see that N3936 doesn't have this bullet point in [basic.def.odr]/2. Sorry for this. I'll edit the question, to make it more clear. – João Afonso Mar 10 '17 at 18:50
  • @JoãoAfonso Ah, if it was only added after that answer was written, that might already be the answer to your question. –  Mar 10 '17 at 19:02

1 Answers1

0

Whoever drafted the list of "potential results" probably just forgot to include the one you're referring to. Core issue 1926 was filed and the issue was fixed in C++17; int a = A::a[0]; does not odr-use A::a (assuming the array element type is int). The resolution was DRed, so you can think of it as being retroactive. Evidently, it was never intended to make this odr-use A::a in the earlier draft (assuming the element type is int).

Separately, another issue was discovered with the wording, which is that it relied on the idea of an lvalue-to-rvalue conversion being performed on the object whose odr-use is in question (in this case the array A::a), but you can't do an lvalue-to-rvalue conversion on an array glvalue. This is CWG2170 and it was also accepted as a DR.

Brian Bi
  • 111,498
  • 10
  • 176
  • 312