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.

      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: link
Be 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).