From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74638 invoked by alias); 7 Jun 2015 08:13:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 74601 invoked by uid 89); 7 Jun 2015 08:12:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ie0-f170.google.com Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 07 Jun 2015 08:12:58 +0000 Received: by iebgx4 with SMTP id gx4so80952053ieb.0; Sun, 07 Jun 2015 01:12:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.30.105 with SMTP id r9mr7006568igh.11.1433664775729; Sun, 07 Jun 2015 01:12:55 -0700 (PDT) Received: by 10.36.152.8 with HTTP; Sun, 7 Jun 2015 01:12:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 07 Jun 2015 08:33:00 -0000 Message-ID: Subject: Re: [v3 PATCH] Implement N4387 and LWG 2367 From: Ville Voutilainen To: libstdc++@gcc.gnu.org Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00509.txt.bz2 On 7 June 2015 at 09:53, Marc Glisse wrote: > Since the paper does not mention looking at _MoveConstructibleTuple or > _ImplicitlyMoveConvertibleTuple here, could you add a comment explaining > why that is needed? Sure. > Does the following code still compile with your patch? > struct A { int a,b; }; > std::tuple a(3,4,{1,2}); No. :/ And we have no test for it.. I'll need to look at that. > IMO the parts with is_default_constructible point to a core issue, we should > not have to duplicate information, especially in such a convoluted way. But > I guess that has lower priority than noexcept(auto), and I haven't yet > looked if concepts will help. Concepts would help a lot, but being able to use them in a library implementation is some ways off. > You use a lot: typename enable_if::type=true > while the current code seems to favor: class=typename enable_if::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. > Introducing > typename _XXX = _TC<(sizeof...(_Elements) == sizeof...(_UElements)), > _Elements...> > and then using _XXX::template thing() might give less clutter when you have > to repeat it 4 times. Sounds good, I'll give it a spin.