[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We need to be careful about this in SFINAE contexts. It can't be a hard error,
because it's extremely common for constructors to be constrained with
std::is_constructible, and for overload resolution to consider constructors for
incomplete types.

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #3 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> We need to be careful about this in SFINAE contexts. It can't be a hard
> error, because it's extremely common for constructors to be constrained with
> std::is_constructible, and for overload resolution to consider constructors
> for incomplete types.

Hmm? but the standard says that a precondition for std::is_constructible is the
type being complete, and we enforce that with a static_assert (since PR71579). 
Why would it be a problem for the builtin to enforce it as well?

I'm also not sure why it's a problem that the builtin doesn't enforce it, for
the same reason.  But I guess it might as well for consistency.

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #3)
> Hmm? but the standard says that a precondition for std::is_constructible is
> the type being complete, and we enforce that with a static_assert (since
> PR71579).  Why would it be a problem for the builtin to enforce it as well?

...having tried it, one reason not to is that it makes the diagnostic worse:
instead of one understandable error from the static_assert, we also get the
compiler error, and then another one from trying to access ::value in the class
we failed to instantiate.

Do other standard library implementations depend on the compiler to diagnose
this?

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 52674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52674&action=edit
patch

Like so.

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #4)
> Do other standard library implementations depend on the compiler to diagnose
> this?

I don't think they enforce it at all (it's IFNDR).

[Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #3)
> Hmm? but the standard says that a precondition for std::is_constructible is
> the type being complete, and we enforce that with a static_assert (since
> PR71579).  Why would it be a problem for the builtin to enforce it as well?

It's a problem when the standard is wrong :-)
https://cplusplus.github.io/LWG/issue2939

We certainly need a complete type for is_constructible<T> and
is_constructible<int, T> and for is_assignable<int, T> (which is PR 109997),
but we don't need a complete type for:

__is_constructible(T&&, T)         // currently true
__is_constructible(T&, T)          // currently false
__is_nothrow_constructible(T&&, T) // currently ill-formed!
__is_convertible(T, T&&)           // currently ill-formed!

The last two seem wrong, we should be able to give a correct answer. See PR
100667.

https://wg21.link/p1285r0 changed the library traits to say that it's only
undefined to instantiate the traits with incomplete types if "instantiation
could yield a different result were T hypothetically completed".

So std::is_constructible_v<T&&, T> is not undefined (because completing T
doesn't change the fact that you can always bind T&& to an rvalue of type T)
and so we should not reject it.