From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 303353858C27; Fri, 5 Mar 2021 07:20:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 303353858C27 From: "xmh970252187 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/99399] New: why does not a pack expansion that is a using-delcaration which intends to introduce the base classes's constructor accept by GCC Date: Fri, 05 Mar 2021 07:20:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: xmh970252187 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 07:20:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99399 Bug ID: 99399 Summary: why does not a pack expansion that is a using-delcaration which intends to introduce the base classes's constructor accept by GCC Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xmh970252187 at gmail dot com Target Milestone: --- template struct A:T...{ using T::T...; }; int main() { } This should have to be well-formed code is rejected by GCC while Clang acce= pts it.=20=20 Here is the result (https://godbolt.org/z/a583Po)=20=20 As per [temp.variadic#5.2] > In a using-declaration; the pattern is a using-declarator.=20=20 Which means the pattern is `T::T`.=20 As per [temp.variadic#7]:=20=20=20 > The pattern of a pack expansion shall name one or more packs that are not= expanded by a nested pack expansion; such packs are called unexpanded pack= s in the pattern. All of the packs expanded by a pack expansion shall have = the same number of arguments specified. There are two unexpanded packs in the pattern and they have the same number= of arguments.=20=20 As per [temp.variadic#6] and [temp.variadic#8.1] > For the purpose of determining whether a pack satisfies a rule regarding = entities other than packs, the pack is considered to be the entity that wou= ld result from an instantiation of the pattern in which it appears.=20=20 > if the pack is a template parameter pack, the element is a template param= eter ([temp.param]) of the corresponding kind (type or non-type) designatin= g the ith corresponding type or value template argument;=20=20 That means `T` in the pattern would be considered as a type template parame= ter designating the corresponding template type argument.=20=20 Eventually, as per [class.qual#2.2] > In a lookup in which function names are not ignored26 and the nested-name= -specifier nominates a class C:=20=20 >> in a using-declarator of a using-declaration that is a member-declaratio= n, if the name specified after the nested-name-specifier is the same as the= identifier or the simple-template-id's template-name in the last component= of the nested-name-specifier=20=20 Assume the template parameters would be `class T0, class T1,class T2, ... ,class Tn` , the result of instantiating the pattern `T::T` will produce the list `T0::T0,T1::T1,T2::T2,...Tn::Tn`, which will satisfy the above rule. Hence, the result of instantiating `T::T` can be considered to nominate the corresponding constructor of the class named in the nested-name-specifier.=