https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
Bug ID: 116943
Summary: wrong(?) indication of specialization after (implicit)
instantiation
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ing.russomauro at gmail dot com
Target Milestone: ---
On godbolt, with gcc 14.2, the following program gets
"error: specialization of 'S<void>::Q' after instantiation".
Adding the data member in the primary template class is what triggers the
problem.
However, a different version with the explicit specialization first, makes the
problem disappearing.
As similar reported problems, I found PR 111608, but it is different (and is
not a bug).
template<typename> struct S{
struct Q{};
Q q; // removing this line, the problem disappears
};
/* non-working version where class member Q is refined for the implicit
specialization S<void> */
template<> struct S<void>::Q {
int x;
};
/* working version where explicit specialization is declared first
template<> struct S<void>{
struct Q;
};
struct S<void>::Q {
int x;
};
*/
Is it really forbidden redefining 'Q' which is a class member which another
member (i.e., 'q') depends on ?
Cannot the checks be postponed ? (e.g., when objects for S<void> will be
effectively constructed)
... otherwise, if the implicit instantiation of S<void> referred by "template<>
struct S<void>::Q" really wants to fully generate the class based on the
primary template, it should not even make sense to have the option to redefine
any of its parts, so invalidating the ability to provide redefinition of
members for implicit specializations, as well as to provide multiple
definitions of (different) members for the same implicit specialization,
isn't it ?
Well, as I was studying standard details on this aspects, IMHO there is lack of
details in [temp.expl.spec] about such stuff.
