From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49073 invoked by alias); 30 Nov 2018 11:01:00 -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 48807 invoked by uid 89); 30 Nov 2018 11:00:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=unavailable version=3.3.2 spammy=H*i:sk:CAFk2RU X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Nov 2018 11:00:19 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 820603058FF2; Fri, 30 Nov 2018 11:00:10 +0000 (UTC) Received: from localhost (unknown [10.33.36.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id 03B9D26540; Fri, 30 Nov 2018 11:00:09 +0000 (UTC) Date: Fri, 30 Nov 2018 11:01:00 -0000 From: Jonathan Wakely To: Ville Voutilainen Cc: Ed Smith-Rowland <3dw4rd@verizon.net>, libstdc++ , gcc-patches List Subject: Re: [PATCH, libstdc++] Uniform container erasure for c++20. Message-ID: <20181130110009.GX809@redhat.com> References: <20181126111845.GP28365@redhat.com> <7a17f7a0-b314-d83c-461c-48f6d3dc254d@verizon.net> <20181130102542.GV809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-11/txt/msg02554.txt.bz2 On 30/11/18 12:40 +0200, Ville Voutilainen wrote: >On Fri, 30 Nov 2018 at 12:25, Jonathan Wakely wrote: >> Yes, that's exactly what I had in mind (and what I expect to get >> proposed for C++20 in the near future). >> >> What does everyone else think, should we go ahead and do this? > >Yes, if we are confident that's what will be in C++20. We're not, but we don't need to be. Anything in the current draft could get removed before the final standard. >> The point is that C++20 changed forward_list (and list, for >> consistency) to return the number of removed elements. The reason for >> that is you can't easily find out the size before and after removing >> elements, because forward_list doesn't have a size() member! >> So IMHO the non-member erase should also return the size, and so that Oops, I meant "should also return the number of removed elements", not "the number of removed element and also the new size". >> it's uniform it should do that for all containers not just the lists. > >I don't mind forward_list being an exception. Returning the size from >other containers >is a bit pointless; presumably it would need to return a pair, and >handling that is clunky >even with structured bindings. No need for a pair, sorry for the confusing wording above.