From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 162053857033; Mon, 17 Aug 2020 10:23:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 162053857033 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1597659799; bh=gV74HWwrMVXV0FJ7Z9wxRdmT6IreUtMru1fp/bXR3NU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iZv8x9Iyx8rut8D51BOkuB1omnB8wHMtEVZ0jHr4sLC+N6aOx54KH4kudhEvJuOa3 Q2/+zI9osbwmDckFSWUgVOg4NMXNDTCM8h2IaaZvXN3fhbJ4eM4RhVZFgdUIcV6pGy gCZ6H+pnfsKl6/4OH7Rk8d6xzYlY7ZmFMxS8fXuA= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/94062] Cannot construct tuple from convertible types Date: Mon, 17 Aug 2020 10:23:18 +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: 9.2.1 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW 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 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: Mon, 17 Aug 2020 10:23:19 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94062 --- Comment #11 from Jonathan Wakely --- > Standard says that if: > std::is_constructible_v=20 > then > std::is_constructible_v, Foo&&> Where does it say that? The fact a constructor participates in overload resolution doesn't mean it = has to be well-formed for all template arguments. > So I think this is not an instance of PR 82113, but an unfortunate > consequence of how tuple is implemented in libstdc++. If tuple elements w= ere > not stored as base classes, but as members than elision is mandatory and = it > would work. Members using [[no_unique_address]] have the same restrictions. > But I guess to fix this you would have to break ABI (or change C++ standa= rd). It wouldn't be an ABI break to make this compile with our std::tuple, becau= se it never compiled previously. But I'm a little uncomfortable with making the ABI of std::tuple depend on whether its elements are copy constructible, ra= ther than just on the elements' layout. That would mean that std::tuple changes layout if you later add a move constructor to Bar.=