16

Consider the following code:

template<typename T>
struct S { static constexpr int bar = T::foo; };

struct U: S<U> { static constexpr int foo = 42; };

int main() { }

GCC v6.1 compiles it, clang 3.8 rejects it with the error:

2 : error: no member named 'foo' in 'U'
struct S { static constexpr int bar = T::foo; };

Which compiler is right?
Could it be due to the fact that U is not a complete type at the point where we try to use it within S?
In this case, it should be considered a bug of GCC, but I'd like to know if I'm right before to search/open an issue on the bug tracker...

EDIT

Meanwhile I've opened a bug to GCC.
Waiting for it to accept the answer.

skypjack
  • 49,335
  • 19
  • 95
  • 187
  • 1
    The latest batch of updates to the Standard working draft include changes to [9.2.3.2p3] related to the new concept of *inline variables* (`constexpr` variables are now implicitly *inline*, just like functions), so the answer for C++17 may change; the current one still holds true for C++14 and below. I'll wait for the latest version of the spec to be published in the official mailing and then I'll update the answer with C++17-specific information. – bogdan Jul 04 '16 at 11:34
  • @bogdan Wow, thank you very much. Really appreciated. – skypjack Jul 04 '16 at 11:35
  • @bogdan Wow, thank you! Unfortunately I can't upvote you twice, but I can accept the answer for I forgot to do that time ago. Sorry and thank you again. – skypjack Jul 23 '16 at 13:33
  • No worries. Cheers! – bogdan Jul 23 '16 at 13:46

1 Answers1

9

For C++14 and 11, Clang is right; however, things have changed in the latest working draft (the future C++17) - see the next section.

The Standard quotes to look for are (from N4140, the draft closest to C++14):

[temp.inst]/1:

[...] The implicit instantiation of a class template specialization causes the implicit instantiation of the declarations, but not of the definitions, default arguments, or exception-specifications of the class member functions, member classes, scoped member enumerations, static data members and member templates; [...]

[temp.point]/4:

For a class template specialization, [...] the point of instantiation for such a specialization immediately precedes the namespace scope declaration or definition that refers to the specialization.

So, the point of instantiation for S<U> is right before the declaration of U, with only a forward declaration struct U; conceptually inserted before, so that the name U is found.

[class.static.data]/3:

[...] A static data member of literal type can be declared in the class definition with the constexpr specifier; if so, its declaration shall specify a brace-or-equal-initializer in which every initializer-clause that is an assignment-expression is a constant expression. [...] The member shall still be defined in a namespace scope if it is odr-used (3.2) in the program and the namespace scope definition shall not contain an initializer.

According to the paragraph quoted above, the declaration of bar within the definition of S, even though it has an initializer, is still just a declaration, not a definition, so it's instantiated when S<U> is implicitly instantiated, and there's no U::foo at that time.

A workaround is to make bar a function; according to the first quote, the function's definition will not be instantiated at the time of the implicit instantiation of S<U>. As long as you use bar after the definition of U has been seen (or from within the bodies of other member functions of S, since those, in turn, will only be instantiated separately when needed - [14.6.4.1p1]), something like this will work:

template<class T> struct S 
{
   static constexpr int bar() { return T::foo; }
};

struct U : S<U> { static constexpr int foo = 42; };

int main()
{
   constexpr int b = U::bar();
   static_assert(b == 42, "oops");
}

Following the adoption of P0386R2 into the working draft (currently N4606), [class.static.data]/3 has been amended; the relevant part now reads:

[...] An inline static data member may be defined in the class definition and may specify a brace-or-equal-initializer. If the member is declared with the constexpr specifier, it may be redeclared in namespace scope with no initializer (this usage is deprecated; see D.1). [...]

This is complemented by the change to [basic.def]/2.3:

A declaration is a definition unless:
[...]

  • it declares a non-inline static data member in a class definition (9.2, 9.2.3),

[...]

So, if it's inline, it's a definition (with or without an initializer). And [dcl.constexpr]/1 says:

[...] A function or static data member declared with the constexpr specifier is implicitly an inline function or variable (7.1.6). [...]

Which means the declaration of bar is now a definition, and according to the quotes in the previous section it's not instantiated for the implicit instantiation of S<U>; only a declaration of bar, which doesn't include the initializer, is instantiated at that time.

The changes in this case are nicely summarized in the example in [depr.static_constexpr] in the current working draft:

struct A {
   static constexpr int n = 5; // definition (declaration in C++ 2014)
};

const int A::n; // redundant declaration (definition in C++ 2014)

This makes GCC's behaviour standard-conformant in C++1z mode.

bogdan
  • 9,229
  • 2
  • 33
  • 48
  • I don’t think any forward declaration of `U` is inserted, nor need be: `S` doesn’t need to look up the *name* `U`, only the name `T` that is a *typedef-name* for the *class* `U`. – Davis Herring May 23 '19 at 02:41
  • @DavisHerring *Conceptually* inserted. It's just one way to think about how specializations are generated; compilers don't have to do it this way, but it is one way to think about points of instantiation that is consistent with the standard rules (allowing for the special dependent name lookup rules and so on, of course). I didn't make this up myself, I've seen compiler writers use this model to discuss the matter. – bogdan May 23 '19 at 08:24
  • @DavisHerring Even if you prefer to think about it using `T` as a typedef-name that keeps being conceptually redefined before each specialization is generated, in order to define that alias, you need a declaration for the thing it aliases visible before it, so you still need that forward declaration of the class `U`. – bogdan May 23 '19 at 08:24
  • Those special dependent name rules are sensitive to whether, say, a function `f` whose address is used as a template argument in its own definition is “declared” early in order to be so referenced. If the template in turn tries to find `f` via dependent ADL, it’s ill-formed NDR if `f` hasn’t been declared yet. For a class, though, it probably doesn’t matter, although I disagree that a declaration must exist for the target of a *typedef-name*; consider `using X=decltype(new int***);`, where `X` names a type never declared and never before used. – Davis Herring May 23 '19 at 19:06
  • @DavisHerring Yes, hence "allowing for the special dependent name lookup rules and so on". That conceptual declaration is just a simple way to visualize the substituted template argument, nothing more. It shouldn't be seen as affecting anything else (if it behaved like a real declaration, I can think of at least one contrived scenario affecting class names too, but that's not the point). Regarding the alias, "the thing it aliases" is in this case `class U`; of course we can find other constructs that don't involve declarations, but I don't think they're relevant to our case. – bogdan May 23 '19 at 20:58