This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3 PATCH] Implement N4387 and LWG 2367
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: 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: Sun, 7 Jun 2015 11:33:45 +0300
- Subject: Re: [v3 PATCH] Implement N4387 and LWG 2367
- Authentication-results: sourceware.org; auth=none
- References: <CAFk2RUZEEUFNeNdOpLdvGAcYZTk2+5B4HTRz5rfTaZHSBJBxJw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 20 dot 1506070748560 dot 2000 at laptop-mg dot saclay dot inria dot fr> <CAFk2RUZO75qesPR11wNp-mcz5wi5ArnE2_oFk5U=iV_YWUHnNQ at mail dot gmail dot com>
On 7 June 2015 at 11:12, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> Does the following code still compile with your patch?
>> struct A { int a,b; };
>> std::tuple<int,int,A> a(3,4,{1,2});
>
> No. :/ And we have no test for it.. I'll need to look at that.
Ahem, yes, this is because the constructor that used to take _Elements
now takes _UElements. I can change it back to take _Elements, because
the technique that the default constructors use allow making the signature
dependent enough that it will sfinae correctly.
>> You use a lot: typename enable_if<X, bool>::type=true
>> while the current code seems to favor: class=typename enable_if<X>::type.
>> I don't really care which one is used, but it is easier to read when the
>> style is consistent through the library.
> It's not a style issue. That template parameter needs to be a non-type one,
> otherwise the overloads are ambiguous.
...and I think it doesn't necessarily need to be non-type, I think it can be
made to work with a type parameter that is enable_if<X, true_type>
and enable_if<X, false_type> for the mutually-exclusive overloads.