From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 33EE03835801 for ; Thu, 3 Jun 2021 12:11:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33EE03835801 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-241-DT-BsTAtPGyBEH6jX7wnGA-1; Thu, 03 Jun 2021 08:10:56 -0400 X-MC-Unique: DT-BsTAtPGyBEH6jX7wnGA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 64CDF6D595; Thu, 3 Jun 2021 12:10:55 +0000 (UTC) Received: from localhost (unknown [10.33.37.1]) by smtp.corp.redhat.com (Postfix) with ESMTP id D30895C232; Thu, 3 Jun 2021 12:10:54 +0000 (UTC) Date: Thu, 3 Jun 2021 13:10:54 +0100 From: Jonathan Wakely To: Patrick Palka Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH] libstdc++: Simplify range adaptors' forwarding of bound args when possible Message-ID: References: <20210514182749.602087-1-ppalka@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210514182749.602087-1-ppalka@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 12:11:12 -0000 On 14/05/21 14:27 -0400, Patrick Palka via Libstdc++ wrote: >r11-8053 rewrote the range adaptor implementation in conformance with >P2281, making partial application act like a SFINAE-friendly perfect >forwarding call wrapper. Making SFINAE-friendliness coexist with >perfect forwarding here requires adding fallback deleted operator() >overloads (as described in e.g. section 5.5 of wg21.link/p0847r6). But >unfortunately, as reported in PR100577, this necessary technique of >using of deleted overloads regresses diagnostics for ill-formed calls to >partially applied range adaptors in GCC. > >Although GCC's diagnostics can arguably be improved here by having the >compiler explain why the other candidates weren't viable when overload >resolution selects a deleted candidate, we can also largely work around >this on the library side (and achieve more concise diagnostics than by >a frontend-side improvement alone) if we take advantage of the >observation that not all range adaptors need perfect forwarding call >wrapper semantics, in fact only views::split currently needs it, because >all other range adaptors either take no extra arguments or only >arguments that are expected to be freely/cheaply copyable, e.g. function >objects and integer-like types. (The discussion section of P2281 goes >into detail about why views::split is special.) > >To that end, this introduces opt-in flags for denoting a range adaptor >as having "simple" extra arguments (in the case of a range adaptor >non-closure) or having a "simple" call operator (in the case of a range >adaptor closure). These flags are then used to conditionally simplify >the operator() for the generic _Partial and _Pipe class templates, down >from needing three overloads thereof (including one defined as deleted) >to just needing a single overload. The end result is that diagnostic >quality is restored for all adaptors except for views::split, and >diagnostics for the adaptors are generally made more concise since >there's only a single _Partial/_Pipe overload to diagnose instead of >three of them. > >Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11? OK for trunk and 11. Is there any benefit in using [[no_unique_address]] for _Partial::_M_args too?