From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B999638582A0; Mon, 18 Dec 2023 11:18:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B999638582A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702898300; bh=50783fVEUjaOtuBfer4KM+8mMPxSPZXXkPXt8JfDzmY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=q1KEGCgRQnV6NDuDRVUDmBDHWD2gb4GR1uPFJ6cftVC54o5qbT3EvtNeWD/WnWNcd IxoUm5YJyFGBIXNkfGIs+9nEqpEi8xC5kJaBiHJ/FiKNUYlgZ0+ptvldwp0DfYp+wd hCrR3GAH/RlZfJJQA85SpGbiBzYwZGcV0xTQ1mFA= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/113060] std::variant converting constructor/assignment is non-conforming after P2280? Date: Mon, 18 Dec 2023 11:18:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi 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: --- 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=3D113060 --- Comment #1 from Jonathan Wakely --- (In reply to Giuseppe D'Angelo from comment #0) > GCC 14 implements P2280 (see #106650).=20 N.B. if you say "Bug 106650" or "PR 106650" or "bug #106650" or pretty much anything except just #106650 then bugzilla makes it a clickable link :) > it seems that variant should indeed accept construction from IC. I'm not convinced that this change to the semantics of std::variant was an intended side effect of https://wg21.link/P2280 -- I think I'd prefer if the committee confirmed it. The standard doesn't say that it _should_ work in a constant expression, it seems like you're assuming that because it's now possible to implement it so that it works, that it's required to work. My reading of [variant.ctor] p14 is that "some invented variable x" is not a constant expression, so using std::declval as a stand-in for "some invented variable" is fine. If we made this change, then some cases that compile today would become ill-formed, e.g. see PR 113007. Under your reading, conversion from the constant 42 would be valid for both int64_t and double, and so the initialization would be ill-formed. But it would be well-formed when using a non-constant int equal to 42. Apart from the fact it would be a breaking change, the difference in behavi= our between runtime and compile time would be surprising. It would also mean th= at std::is_constructible would be misleading: it would say you can construct variant from 42, but when you try to do that it would fail to compile.=