From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 12EEB3851C34; Mon, 17 Aug 2020 12:02:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12EEB3851C34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1597665773; bh=kdJ617E0Ih8GflKsT6wiR0EAuwJwpW1jcrBc2wqqITA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ah4/JQsXqouiKP3UOvIxqg4pxWMYnvFWFkUrxZjDxmQ6NNma3bvvReTSlG1nPPjx8 kiMGZGRjn91AYAq//mJoLoTUX8R4SO4xF6CCVaofYkwIRGxrEYavoGLYTBIkJejVgD cx1JeZwLtPUMzhDLTR8ttj2NRG7H6fCPIJ2boxIU= From: "m.cencora at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/94062] Cannot construct tuple from convertible types Date: Mon, 17 Aug 2020 12:02:52 +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: m.cencora at gmail dot com 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 12:02:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94062 --- Comment #12 from m.cencora at gmail dot com --- (In reply to Jonathan Wakely from comment #11) > > Standard says that if: > > std::is_constructible_v=20 > > then > > std::is_constructible_v, Foo&&> >=20 > Where does it say that? >=20 > The fact a constructor participates in overload resolution doesn't mean it > has to be well-formed for all template arguments. Indirectly from following paragraph 20.5.3.1 in latest C++ draft: template constexpr explicit(see below) tuple(UTypes&&... u= ); 11 # Constraints: sizeof...(Types) equals sizeof...(UTypes) and sizeof...(Types)= =E2=89=A51 and is_=C2=ADconstructible_=C2=ADv is true for all i. 12 # Effects: Initializes the elements in the tuple with the corresponding value= in std=E2=80=8B::=E2=80=8Bforward(u). 13 # Remarks: The expression inside explicit is equivalent to: !conjunction_v...> So unless I am missing something, I see no escape hatch for making such constructor ill-formed for some types. >=20 > > 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= were > > not stored as base classes, but as members than elision is mandatory an= d it > > would work. >=20 > Members using [[no_unique_address]] have the same restrictions. >=20 > > But I guess to fix this you would have to break ABI (or change C++ stan= dard). >=20 > It wouldn't be an ABI break to make this compile with our std::tuple, > because 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, rather than just on the elements' layout. >=20 > That would mean that std::tuple changes layout if you later add a mo= ve > constructor to Bar. Not sure how, because you can create std::tuple already by using other constructors, e.g.: #include struct Bar { Bar() =3D default; Bar(int i); Bar(const Bar&) =3D delete; }; struct ConvertibleToBar { operator Bar(); }; std::tuple ok1() { return {}; } std::tuple ok2() { return {0}; } std::tuple fail1() { return {ConvertibleToBar{}}; }=