This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3 PATCH] PR libstdc++/70437
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 5 Apr 2016 12:25:53 +0100
- Subject: Re: [v3 PATCH] PR libstdc++/70437
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUb+RBM7oK+33pMvz5VNhcPo+7eVpZJOyX8VyecPj0puvg at mail dot gmail dot com> <CAFk2RUaMgb6g3wULKZQFNtdsYVN1y94c_SzkJVCFW29wzLHz7A at mail dot gmail dot com> <20160405105306 dot GD5814 at redhat dot com> <CAFk2RUY+vM4kLXHH6hE1CLTo9PJgqcbL82-pGvpyZWi4URb_4A at mail dot gmail dot com>
On 05/04/16 14:07 +0300, Ville Voutilainen wrote:
On 5 April 2016 at 13:53, Jonathan Wakely <jwakely@redhat.com> wrote:
I wonder if we want an __is_samey trait that checks if two decayed
types are the same.
If such checks become more common, then yes. For now, perhaps not.
We already do it in packaged_task, function, any, and optional.
I'll look into doing that in stage 1.
More seriously, a comment might be useful to explain that although
these "concepts" return true for samey types, that is just to prevent
is_constructible from getting into a mess with incomplete types, and
actually for samey types one of the special member functions might end
up being chosen by overload resolution instead.
Did I get that right? If so, I definitely think it's worth a comment,
as I for one won't remember the details in a few months!
How about the attached new patch?
Great - OK for trunk, thanks.
I just added a comment at the top of these
"concept utilities". In general, there's an unfortunate amount of such trickery
needed to get pair and tuple right as far as their constraints go, to protect
the innocent overloads from getting input that they can't cope with, as such
constraints are evaluated during overload resolution, and in some cases that
evaluation will be done even for overloads that will certainly not be
chosen, but
they have to be prepared for input that is hard to digest. That's one of the
reasons why 'if constexpr' will be a godsend, but I should not digress
there right now. :)
I'd sell a kidney for `if constexpr` right now ;-)