From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E95AA385841F; Thu, 22 Feb 2024 22:50:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E95AA385841F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708642215; bh=3itubtqbXAtrWBWNSvwXOc7DtveHY1oXjhJ63sG8bvc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fntC6jqm5uLZH/Ve7drxh7Jta+oAoexw+BVzUqfZDdBIdQF92di3NXY7YRlm6IE1g sWgOOPLK84lANjJUlRvlZy4GQDNwtbdHYB7wJyf39H6FsDfI4N3SnneXFp3z21/YDH w4y0g6Bs3eI79aNDmtJQ1sDvLo5nUlwoKbV951f8= From: "webrown.cpp at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/104111] [DR2589] Concept evaluation depends on context where it was first checked Date: Thu, 22 Feb 2024 22:50:13 +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: accepts-invalid, rejects-valid, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: webrown.cpp at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ppalka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104111 --- Comment #10 from W E Brown --- (In reply to Eric Estievenart from comment #9) Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 c= ode as shown. Rather, I believe it to be simply an example of a program that t= he C++ standard would describe as "ill-formed, no diagnostic required." A common, yet incorrect expectation that template instantiation somehow mir= rors function call semantics seems to me to lie at the heart of the misunderstanding. Hypothetically, if the above program were to be well-for= med, the compiler would need to instantiate the member template twice *with identical template arguments* in order to obtain the expected two different outcomes. However, I recall no specification, in the C++ standard, that requires such (relatively expensive!) duplication of compiler effort: once= a template has been instantiated, the compiler seems fully entitled, say, to cache the result of that instantiation and reuse that outcome as may be nee= ded during the remainder of that TU's compilation. Put another way, defining the same function in two different ways (one instantiation as deleted, one not) seems to be a form of ODR violation. Perhaps the OP is also a manifestation of a similar misunderstanding; I've = not checked. If so, I would respectfully recommend this PR be closed as invali= d.=