This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: tuple move constructor
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 7 May 2016 02:31:00 +0300
- Subject: Re: tuple move constructor
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1604202233060 dot 21596 at laptop-mg dot saclay dot inria dot fr> <CAH6eHdRO6kfWqb5K_Nr5WYvHCJNNyQeKSN8VF5c-Ov32HOpU4g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1604211902320 dot 27091 at laptop-mg dot saclay dot inria dot fr> <alpine dot DEB dot 2 dot 20 dot 1605061944340 dot 2019 at laptop-mg dot saclay dot inria dot fr> <CAFk2RUbFQ364fBXbhpmpGJsfqNSxiDbm7vnB=ViUfmKkSap7ww at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1605062307220 dot 2019 at laptop-mg dot saclay dot inria dot fr>
On 7 May 2016 at 00:39, Marc Glisse <marc.glisse@inria.fr> wrote:
> Assuming we want the copy constructor to be defaulted, I think we still
> could with concepts:
>
> tuple(tuple const&)
> requires(__and_<is_copy_constructible<_Elements>...>::value)
> = default;
>
> While there is precedent for enabling C++11 features in C++03 mode inside
> system headers, I guess maintainers might be more reluctant for something
> that is only heading for a TS for now.
Much as I'd like to go towards that direction, I don't think we can,
yet, at least not as our default
implementation, because front-ends like clang wouldn't be able to
compile our library.
>> I think the patch is ok, but I think it would be a good idea to have a
>> comment on the added tag type and its purpose.
> Indeed. I wasn't sure if people preferred more tags or more enable_if...
I don't have a strong opinion if there's implementation choice between those.