This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH] Avoid endless run-time recursion for copying single-element tuples where the element type is by-value constructible from any type
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: Daniel KrÃgler <daniel dot kruegler at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 8 May 2016 15:55:02 +0300
- Subject: Re: [v3 PATCH] Avoid endless run-time recursion for copying single-element tuples where the element type is by-value constructible from any type
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUbNSFqrX5kuEK-yd14verEu=ttGiq-Njm5=UhyMchvJVg at mail dot gmail dot com> <CAGNvRgAV-C3OJvTftCYhwiNzO4SQqPpqajUJh6aBXAHGf29f6w at mail dot gmail dot com> <CAFk2RUb+M+DGT4ZgWWE6zxScjGnECeqh9e4qU7T1Lvk9LsPyZw at mail dot gmail dot com>
On 8 May 2016 at 14:51, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 8 May 2016 at 14:48, Daniel KrÃgler <daniel.kruegler@gmail.com> wrote:
>> Have you considered to test against decay instead of
>> remove_reference/remove_const? That would be similar to other places
>> in the standard. (I also believe that your fix actually should be
>> submitted as an LWG issue)
>
>
> STL is about to submit the fix as an LWG issue. He seemed to agree
> that the fix is what
> he intends to submit. Using decay instead of
> remove_reference/remove_const is fine by
> me, but I suppose it shouldn't make a difference here other than
> notational brevity?
For what it's worth, I have the tiniest preference against using decay
here; whenever I see
decay, I wonder whether array/function decay is significant. While it
doesn't make a difference
here, I still prefer just doing remove_reference+remove_const here.
It's up to Jonathan, I'll change
it to decay if he so advises.