https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression]
|std::variant default |[CWG2335] std::variant
|constructor |default constructor and
| |unparsed DMI
--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Eyal Rozenberg from comment #12)
> (In reply to Jason Merrill from comment #8)
> > We cannot correctly resolve is_nothrow_constructible<A> until we've parsed
> > the DMI. Given that, we have three options:
> >
> > 1) Conservatively say no.
> > 2) Optimistically guess yes.
> > 3) Non-SFINAE error.
> >
> > ("We" in this sentence is the C++ standard.)
>
> But in this page, "we" is the compiler. IIUC, the standard does not allow
> for determing is_nothrow_constructible<A>. Am I correct? If that really is
> the case, shouldn't the compiler emit an error saying that?
Indeed, that's the question.
> Alternatively, when not following the standard strictly, why should it not
> be option (4.): Ignore the official restriction on determining (nothrow)
> constructibility, make a best-effort attempt to determine it anyway ( which
> in this example should succeed), and report failure otherwise.
>
> ?
If we can define such a best-effort attempt, it could be a candidate for
standardization.
> > PR81359 changed our behavior from 3 to 1.
>
> I searched that bug page for the rationale, and couldn't quite get it.
The patch made the error about depending on an unparsed initializer subject to
SFINAE, so that the implicit default ctor just isn't a viable candidate in this
context. So for the testcase in comment #1, A is not default-constructible
until we reach the end of DataWithStruct.
The problem comes when we cache this answer in the is_default_constructible
class; now the rest of the compilation thinks A isn't default-constructible
because we happened to check it within DataWithStruct.
This seems analogous to type completeness; if A were forward-declared, and the
definition moved after the is_default_constructible test, we'd have the same
situation. But that the standard library traits require that their argument be
complete, which avoids the caching problem at the top level, though we might
still end up caching based on the completeness of some intermediary.
The traits completeness requirement seems to suggest that making the unparsed
initializer a hard error again is the right way to go. But I'm uneasy about
making this change at this point in GCC 12 stage 4; I'm definitely not going to
backport it.
