public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
@ 2022-03-22 21:28 ` redi at gcc dot gnu.org
2022-03-23 13:42 ` jason at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-22 21:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
2022-03-22 21:28 ` [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed redi at gcc dot gnu.org
@ 2022-03-23 13:42 ` jason at gcc dot gnu.org
2022-03-23 13:46 ` jason at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2022-03-23 13:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
2022-03-22 21:28 ` [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed redi at gcc dot gnu.org
2022-03-23 13:42 ` jason at gcc dot gnu.org
@ 2022-03-23 13:46 ` jason at gcc dot gnu.org
2022-03-23 16:18 ` jason at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2022-03-23 13:46 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2022-03-23 13:46 ` jason at gcc dot gnu.org
@ 2022-03-23 16:18 ` jason at gcc dot gnu.org
2022-03-23 16:39 ` jason at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2022-03-23 16:18 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2022-03-23 16:18 ` jason at gcc dot gnu.org
@ 2022-03-23 16:39 ` jason at gcc dot gnu.org
2022-03-23 18:14 ` redi at gcc dot gnu.org
2024-03-27 15:12 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: jason at gcc dot gnu.org @ 2022-03-23 16:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2022-03-23 16:39 ` jason at gcc dot gnu.org
@ 2022-03-23 18:14 ` redi at gcc dot gnu.org
2024-03-27 15:12 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2022-03-23 18:14 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2022-03-23 18:14 ` redi at gcc dot gnu.org
@ 2024-03-27 15:12 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: redi at gcc dot gnu.org @ 2024-03-27 15:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-03-27 15:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-92067-4@http.gcc.gnu.org/bugzilla/>
2022-03-22 21:28 ` [Bug c++/92067] __is_constructible(incomplete_type) should make the program ill-formed redi at gcc dot gnu.org
2022-03-23 13:42 ` jason at gcc dot gnu.org
2022-03-23 13:46 ` jason at gcc dot gnu.org
2022-03-23 16:18 ` jason at gcc dot gnu.org
2022-03-23 16:39 ` jason at gcc dot gnu.org
2022-03-23 18:14 ` redi at gcc dot gnu.org
2024-03-27 15:12 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).