Repository navigation
CWG3226 [temp.res.general] It seems wrong to restrict IFNDR when no valid specialization can be generated to when "the innermost enclosing template is not instantiated" #973
Description
Activity
I believe this isn't IFNDR, but rather a hard compiler error. Because
thispoints to the class templateFoo<T>, the expressionthis->bar()depends on the template parameter.Under C++ template two-phase lookup rules, name lookup for a member of a dependent expression (
this->bar()) is deferred until the template is instantiated (in this case it isFoo<int>).When
Foo<int>is instantiated, the compiler performs the lookup for bar insideFoo<int>. Sincebaris never declared anywhere inFoo, the lookup fails, and the compiler must emit a diagnostic error message.On x86-64 GCC 16.2:
<source>: In constructor 'Foo<T>::Foo(T)': <source>:7:15: error: 'struct Foo<T>' has no member named 'bar' [-Wtemplate-body] 7 | this->bar(); | ^~~@justs0cold
Foo<int> f;doesn't instantiate the definition of the constructorFoo(T), only its declaration, so it can't cause this error. The error you're seeing is reported by GCC when first seeing the template, not when instantiating it (as you can see here by commenting outFoo<int> f;). GCC sees it as IFNDR under the "no valid specialization can be generated" rule.My point is that the wording of "no valid specialization" rule is defective, because the wording says it becomes well-formed once I instantiate the enclosing class
Foo<int>, even if I don't instantiate the offending constructor.@HolyBlackCat Ah, you are completely correct. If I'm not wrong, GCC 15 and 16 introduced early diagnostic checks under the flag
-Wtemplate-body, which analyzes the primary template definition, seesFoo<T>lacks abarmember for any generic type, and throws an error during phase 1.Apparently this:
template <typename T> struct Foo { Foo() {} Foo(T) { this->bar(); } };
can compile up to GCC 14.4.
- Reacted by Egor and justs0cold
- changed the title
[-][temp.res.general] It seems wrong to restrict IFNDR when no valid specialization can be generated to when "the innermost enclosing template is not instantiated"[/-][+]CWG3226 [temp.res.general] It seems wrong to restrict IFNDR when no valid specialization can be generated to when "the innermost enclosing template is not instantiated"[/+]on Aug 30, 2026
Full name of submitter (unless configured in github; will be published with the issue): Egor Mikhailov
Reference (section label):
[temp.res.general]/6.1Link to reflector thread (if any): none
Issue description:
The intent of "and the innermost enclosing template is not instantiated" seems to be to remove the IFNDR status if an invalid specialization is actually produced, which in turn makes the program just IF. But the way it's currently worded is problematic.
Example 1:
Both GCC and Clang treat
this->bar();as IFNDR, which matches the intent. But since I haveFoo<int> x;, which causes an instantiation of the innermost enclosing template (which isFoo), under the current wording the program turns from IFNDR to well-formed, which I guess isn't the intent.Similarly, example 2:
I'm sure the intent is for this to be IFNDR, but since I have an instantiation of
a<int>(), this is now well-formed.Suggested resolution:
Or split the sentence to something like
+no valid specialization, ignoring static_assert-declarations that fail ([dcl.pre]), can be generated for a templated entity and that entity is not instantiated, or for a substatement of a constexpr if statement ([stmt.if]) within a templated entity and that substatement is not instantiated, or