From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3AF543858D35; Thu, 23 Sep 2021 14:58:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3AF543858D35 From: "ppalka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists Date: Thu, 23 Sep 2021 14:58:39 +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: 12.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: ppalka at gcc dot gnu.org 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: 11.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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, 23 Sep 2021 14:58:39 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102419 --- Comment #5 from Patrick Palka --- (In reply to Arthur O'Dwyer from comment #4) > > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the con= cept-id X, they appear to be substituting {int} into X's constraint-ex= pression instead of into the normal form of X's constraint-expression. >=20 > Isn't this situation exactly analogous to `std::void_t`? >=20 > template using void_t =3D void; > template auto foo(T t) -> void_t; // SFINAEs > away > template auto foo(T t) -> int; // this is the only viable > candidate > static_assert(std::same_as); >=20 > The language has definitely decided that you can't preemptively fold > `void_t` down to `void`; True, that=20 I don't think you should > be allowed to preemptively fold `Y` down to > `true`, either. > I don't know for sure that Clang/MSVC have been authoritatively dubbed > righteous, but their behavior certainly seems, to me, more consistent and > useful than GCC's. (In reply to Arthur O'Dwyer from comment #4) > > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the con= cept-id X, they appear to be substituting {int} into X's constraint-ex= pression instead of into the normal form of X's constraint-expression. >=20 > Isn't this situation exactly analogous to `std::void_t`? >=20 > template using void_t =3D void; > template auto foo(T t) -> void_t; // SFINAEs > away > template auto foo(T t) -> int; // this is the only viable > candidate > static_assert(std::same_as); >=20 > The language has definitely decided that you can't preemptively fold > `void_t` down to `void`; I don't think you sho= uld > be allowed to preemptively fold `Y` down to > `true`, either. I see what you mean, but I think the constraint normalization process as currently specified forces us to effectively perform such folding.=20 Specifically in the definition of an atomic constraint ([temp.constr.atomic]p1): An atomic constraint is formed from an expression E and a mapping from the template parameters that appear within E to template arguments that are for= med via substitution during constraint normalization in the declaration of a constrained entity. the parameter mapping of an atomic constraint is defined to consist only of= the template parameters that _appear within E_. In this case E is just 'true', which doesn't depend on any template parameters, so the normal form of Y is just 'true (with empty parameter mapping)', which is trivially satisfied for all T. In order to achieve the behavior that you expect, IIUC this definition would need to be changed to say that the parameter mapping of an atomic constraint includes all in-scope template parameters and not only those that appear wi= thin the expression.=