From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1F690393BC23; Thu, 8 Jul 2021 17:05:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F690393BC23 From: "mpolacek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them" Date: Thu, 08 Jul 2021 17:05:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mpolacek at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status assigned_to Message-ID: In-Reply-To: References: 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: Thu, 08 Jul 2021 17:05:04 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98939 Marek Polacek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot= gnu.org --- Comment #1 from Marek Polacek --- (In reply to Jason Merrill from comment #0) > The changes from this paper should not affect a significant amount of cod= e; > many are clarifications that bring the wording in line with existing > practice, some are clarifications of corner cases that most code doesn't > depend on, like ambiguous lookup within a conversion-type-id. >=20 > A few changes that allow code that has been ill-formed: >=20 > conversion-type-id is added to the list of type-only contexts from P0634: >=20 > template struct A { operator T::type(); }; // OK This already works; I fixed it via DR 2413 in GCC 10. > ::template is also not required in type-only contexts: >=20 > template auto f(T t) { return static_cast>(t); } // OK This needs to be implemented, but it's in the spirit of P0634 which I implemented. Strongly related to DR 1478. It's also reminiscent of CWG 96 which is assigned to me. > Default template arguments are now complete-class contexts, like default > function arguments: >=20 > template struct A { > template void g() { } // OK > T t; > }; This is DR 1635 / bug 57314. Since I've dealt with deferred parsing quite often recently (in the context= of deferred noexcept parsing), I might as well tackle this one too. My hope is that the very same trick of stashing the tokens and then reparsing them at = the end of the class will work here too. This will probably need some kind of tparm -> defarg mapping. So it looks like I'm in a position to fix at least parts of this proposal, = thus mine for now. A question worth considering is whether we only want to allow the code in C++23, or whether we really want to treat those issues as DRs, and so allow= the code in previous modes. P0634 is only enabled in C++20, so it makes the be= st sense to me to only allow the above in C++23.=