public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "webrown.cpp at gmail dot com" <gcc-bugzilla@gcc.gnu.org> 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 [thread overview] Message-ID: <bug-104111-4-wx9nev7tOc@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104111-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111 --- Comment #10 from W E Brown <webrown.cpp at gmail dot com> --- (In reply to Eric Estievenart from comment #9) Sorry, but I find neither "weirdness" nor "spooky"-ness in the comment #9 code as shown. Rather, I believe it to be simply an example of a program that the C++ standard would describe as "ill-formed, no diagnostic required." A common, yet incorrect expectation that template instantiation somehow mirrors function call semantics seems to me to lie at the heart of the misunderstanding. Hypothetically, if the above program were to be well-formed, 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 needed 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 invalid.
prev parent reply other threads:[~2024-02-22 22:50 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-19 8:21 [Bug c++/104111] New: " fchelnokov at gmail dot com 2022-01-19 8:22 ` [Bug c++/104111] " fchelnokov at gmail dot com 2022-01-19 8:42 ` pinskia at gcc dot gnu.org 2022-01-19 14:19 ` ppalka at gcc dot gnu.org 2022-01-21 14:27 ` ppalka at gcc dot gnu.org 2022-04-21 7:51 ` rguenth at gcc dot gnu.org 2022-05-27 17:58 ` jason at gcc dot gnu.org 2022-05-27 22:02 ` jason at gcc dot gnu.org 2022-05-31 19:29 ` [Bug c++/104111] [DR2589] " jason at gcc dot gnu.org 2023-05-29 10:06 ` jakub at gcc dot gnu.org 2024-02-22 17:11 ` steve+gcc at tecwec dot eu 2024-02-22 22:50 ` webrown.cpp at gmail dot com [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-104111-4-wx9nev7tOc@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).