Is in-line initialization of a non-const static data member allowed in unevaluated contexts?

user_8372853 0
Viewed 104

The following program

struct S 
{
    template <typename T>
    static auto i = T{};
};

int main()
{
    return decltype(S::i<int>){};
}

is compiled by GCC, but Clang gives an error when S::i is instantiated:

error: non-const static data member must be initialized out of line
    static auto i = T{};
                ^   ~~~

The error makes sense, and if S::i is used in an evaluated context, GCC still compiles the code, but fails to link as it doesn't find the definition of i.

Since GCC sees enough of the initializer of i to know its type, but not enough to know its value, it feels like a GCC bug. On the other hand, in an unevaluated context only the type is needed, so maybe this is ok and it's a Clang bug.

Is this code valid?

language-lawyer templates c++
1 Answers

TLDR

Is in line initialization of a non-const static data member allowed in unevaluated contexts?

Is this code valid?

No and no; this is ill-formed, as decltype(S::i<int>) will require the type of S::i for the int specialization to be deduced, and this requires at least instantiation of the declaration of S::i<int> which in itself is ill-formed (which we may study in isolation by means of explicit instantiation declarations).

A more interesting question, however, is whether decltype(S::i<int>) will, or will not, require instantiation also of the definition of S::i<int>; even though it is not needed solely for the purpose of deducing its type.

Details

Let's start by enumerating what we have here:

  • S::i is formally a static data member template ([temp.def]/1.5)
  • S::i as per its primary template is not inline; neither explicitly using the inline keyword or implicitly by it being constexpr
    • This also holds for all specializations of it, as there are no explicit specializations of it declared as inline ([temp.expl.spec]/12)

This means that the in-class declaration of S::i is not a definition, and as it does not fall under any of the special cases of [class.static.data]/3:

[...] Declarations of other static data members shall not specify a brace-or-equal-initializer.

meaning its declaration shall not contain an initializer expression.

The error makes sense, and if S::i is used in an evaluated context, GCC still compiles the code, but fails to link as it doesn't find the definition of i.

This is where it becomes tricky; to simplyify some let's remove the "odr-need" for a definition from the equation, modifying your own example to the following:

struct S 
{
    template <typename T>
    static auto i = T{};  // #1
};

decltype(S::i<int>)* sp; // #2
// Clang: rejects-valid?
// GCC:   accepts-invalid?

int main() {}

We may start by pointing out that any instantiation, explicitly or implicitly, of even only the declaration of S::i is ill-formed, solely due to the fact that the declaration #1 associated with the specialization (in lack of explicit specializations that may be declared with inline) contains an initializer-expression.

Moreover,

decltype(S::i<int>)* sp; // #2

requires deduction of S::i<int> from its initializer, as per [dcl.spec.auto]/4, but as pointed out above, the very precense of this initializer makes the variable template declaration ill-formed, so this alone should suffice to reject the program. This does not say, however, whether the specialization (or particularly its definition) actually needs to be instantiated or not.

We may note that [dcl.spec.auto]/14 points out that an explicit instantiation declaration does not cause the instantiation of the associated entity, but

[...] it also does not prevent that entity from being instantiated as needed to determine its type.

If we modify the example above accordingly:

struct S 
{
    template <typename T>
    static auto i = T{};  // #1
};

extern template int S::i<int>;

int main() {}

Clang once against rejects the program, as #1 is ill-formed for any specialization, whereas GCC accepts it. Clang is correct here, as auto is not allowed in an explicit instantiation declaration for variable templates, meaning we must specify a non-deduced type, and the type of the explicit instantiation declaration needs to match the deduced type of the primary template declaration for the given specialization (declaration matching); the latter thus requires the type to be deduced, which triggers the erroneous construct at #1.

Based on the final example, GCC clearly has a bug, at least, for the case we only instantiate the (ill-formed) declaration of a given specialization.

It still remains somewhat (formally) unanswered whether an unevaluated context will or will not lead to an implicit instantiation of an entity's definition, however. This overlaps with the following Q&A:

which hints at there possibly being a defect or underspecifiation in the standard regarding whether "implicit instantiation as required to deduce a type" actually also results in instantiation of the entity's definition (even if not informally "needed" for the "as required to").

user_45732470
Related