220 32516 article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposing APi changes to LFv2 Uniform Container Erasure Date: Wed, 17 May 2017 15:59:54 -0700 (PDT) Lines: 194 Approved: news@gmane.org Message-ID: References: <201705171111.22639.marc.mutz@kdab.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_140_1634515155.1495061994741" X-Trace: blaine.gmane.org 1495061998 3693 195.159.176.226 (17 May 2017 22:59:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 17 May 2017 22:59:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIOXK7TZACRUBH76OPHO@isocpp.org Thu May 18 00:59:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dB7v4-0000n2-UW for gclcip-std-proposals@m.gmane.org; Thu, 18 May 2017 00:59:51 +0200 Original-Received: by mail-oi0-f70.google.com with SMTP id w138sf28260788oiw.0 for ; Wed, 17 May 2017 15:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Re5TYu8VXiFJJXtVPMMH7StiEazJUb4TgvcEAth3hd0=; b=NHTM0v2gV5WwIFzFiuTPxNmT2r1Np5lNpNt8i09Uc3OlQ5kTNHMHqSBMJBv4Gb+SVI v3ZRpN9msjJvAFOI2BBux1JX+3hxPhIWgPQk8bZJCvw8xO+QbSCrrES4sfF243jE2C0y Oa17HXLtK3lMMfmK1Svk37CM/dB/BaZzq7H1I/jhtM1aYshUKME4pD/J5lJI/qAc0VXk 8/23FXQJm1idFhwHLcR69C4935mPajlPWfl1dBmMvaR1clbUs7kLIiUOe2AfVqtrEEcl LWcV5g1bCO0bOftotkgoKFv05L9JMpeGzr50Hhcg/WhN3W5AhhaI7CbCojI4j5FfI2Kv Ki5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=Re5TYu8VXiFJJXtVPMMH7StiEazJUb4TgvcEAth3hd0=; b=n/F9zknmvfE62xf/5WUM/D/65uNT8DFdATTLUsRU7CgYwLti2v2g6jivGS4ZvnYGu1 7CrBdMY0U1AGHr/hULjyeVFEs1nKCcWO+wnQdp+rlf4JKaLGNzK/9dPPjHukxfFJgvVe Uo+Za3Ycn7RlVQLGqrjKwswUlZ6316vD6vXZWVRkyE8hUgK+C3Ld1qK1vtH1DY7p4Kq7 /pXoxWtAP/l0Hrg2EP+NYNePriMoY6yTD2WV1kAfJAs+QrZIjAbE3f8L+6wUTs6BhAnp JPX/k26HCrUBBk4EAHySt4qsJbUj201Zqk4ezUYrc8QvgjthAfuuF59alVPWarWvE2kt 8P9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Re5TYu8VXiFJJXtVPMMH7StiEazJUb4TgvcEAth3hd0=; b=JveqrqlyvUJGLTBezc6VLodNErTBvyGsaAESbhrk+Qzd54ExL+sZdrSScLubGq8H3w ZmJ0zNeQj2OWyeR+HOA+AATTcVgEisJbQ8UKmlwWXYpHeYQleJLuVL8dCf4t8vSu65aM T7Wp1YPLWZhDHRL0hv3NLJlTq55DTEqSgAgXTG00G5Dr8wQ9dWqfXdVmnL2n1inrIBbT TUXohMeyHDaEyYvY27nQEtpPO3lBBfH0bCHDh/OQZA67PDYyyZn84MADRjk9g6N1FjIf cmnS2F37zxy3uwGXvX8om2aAUvXDbvMU3U4799kH4SCBXcDwqhx85/k8Pzn8Ruu561R9 /3nw== X-Gm-Message-State: AODbwcC6uhmUJKYkN/MN7gzAuCLVl8ro95IBO/kV84zOoMeEV1Hgqy1B pYl6BFMT3olVzTn8 X-Received: by 10.157.4.231 with SMTP id 94mr656284otm.148.1495061996272; Wed, 17 May 2017 15:59:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.35.25 with SMTP id j25ls4546962otb.33.gmail; Wed, 17 May 2017 15:59:55 -0700 (PDT) X-Received: by 10.157.28.130 with SMTP id l2mr28818ota.17.1495061995220; Wed, 17 May 2017 15:59:55 -0700 (PDT) In-Reply-To: <201705171111.22639.marc.mutz@kdab.com> X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32516 Archived-At: ------=_Part_140_1634515155.1495061994741 Content-Type: multipart/alternative; boundary="----=_Part_141_2133372762.1495061994741" ------=_Part_141_2133372762.1495061994741 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, May 17, 2017 at 3:12:28 AM UTC-6, Marc Mutz wrote: > I have two suggestions on how to improve the API of the erase() > and erase_if() algorithms.=20 > > The first concerns the return type. Alex Stepanov teaches us to not throw= =20 away=20 > useful information, but that is exactly what the functions currently do:= =20 the=20 > implementation knows how many elements were removed, but that information= =20 is=20 > lost upon return from the function. [...] > I therefore propose to change the return type from void to size_t,=20 returning=20 > the number of elements removed.=20 I'm "weakly against" this idea out of general conservativity, but I don't= =20 see anything fundamentally wrong with it. You might equally well propose that the function should return "the last=20 removed element" as std::optional, or some such; isn't that=20 also information that's "thrown away" by the current algorithm? Sure, it'd= =20 cost some performance to do that, but it'd also cost performance to count= =20 the number of removed elements, which otherwise wouldn't need to be tracked= =20 by the algorithm. =20 > [...] For most containers, this is not a=20 > problem, because you can easily (and in constant time) compare the size()= =20 of=20 > the container before and after the application of the algorithm, but that= =20 is=20 > notably not the case for std::forward_list. [...] Surely that's a problem only for the poor misguided users of=20 std::forward_list. :P > The second is about passing std::pair as the argument of the predicate=20 for=20 > erase_if for maps. Yes, from a theoretical POV, passing the value_type is= =20 > consistent. Still, IMO, the algorithm should pass the key and value=20 > separately, as that allows easier extension to associative data=20 structures=20 > that do not store keys and values together, or not as a std::pair (like= =20 e.g.=20 > http://doc.qt.io/qt-5/qhash.html). It would also make for easier=20 predicates,=20 > as they wouldn't need to decompose the pair first (no pun intended).=20 Finally,=20 > it would allow to isolate such predicates from the unfortunate 'first'=20 and=20 > 'second' names (decomposition declarations solve that, too, but at the=20 cost of=20 > another line of code).=20 Agreed that std::pair has a pretty terrible API, but for better or worse,= =20 it *is* the value_type of the container. > As I _do_ see the value in accepting value_type for generic code, how=20 about=20 > the algorithm checks to see whether it can pass key and value separately,= =20 and,=20 > if so, does it, otherwise passes as a pair? Pseudocode:=20 > > if constexpr (__is_binary_predicate(p)) {=20 > if (p(it->first, it->second))=20 > it =3D c.erase(it);=20 > else=20 > ++it;=20 > } else { > if (p(*it))=20 > it =3D c.erase(it);=20 > else=20 > ++it;=20 > } Surely the check should be reversed, since breaking down the pair into=20 separate arguments is "doing more" than just passing a reference to the=20 pair itself? Also, what if 'p' is a generic lambda or something like that, which is=20 callable in several *different* ways? Letting the algorithm choose the=20 signature with which it'll call 'p' seems like a recipe for confusion.=20 Every other algorithm is really explicit about the exact way it's going to= =20 call all its predicate arguments. =E2=80=93Arthur --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/e584f516-f714-4175-a4bf-d89cc242cce6%40isocpp.or= g. ------=_Part_141_2133372762.1495061994741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, May 17, 2017 at 3:12:28 AM UTC-6, Marc Mutz = wrote:
> I have two suggestions on how to improve the API of the eras= e()
> and erase_if() algorithms.
>
> The first concern= s the return type. Alex Stepanov teaches us to not throw away
> usef= ul information, but that is exactly what the functions currently do: the > implementation knows how many elements were removed, but that inform= ation is
> lost upon return from the function. [...]
> I there= fore propose to change the return type from void to size_t, returning=C2=A0=
> the number of elements removed.=C2=A0

I'm "weakly = against" this idea out of general conservativity, but I don't see = anything fundamentally wrong with it.
You might equally well propose th= at the function should return "the last removed element" as std::= optional<value_type>, or some such; isn't that also information t= hat's "thrown away" by the current algorithm? =C2=A0Sure, it&= #39;d cost some performance to do that, but it'd also cost performance = to count the number of removed elements, which otherwise wouldn't need = to be tracked by the algorithm.
=C2=A0
> [...] For most con= tainers, this is not a
> problem, because you can easily (and in con= stant time) compare the size() of
> the container before and after t= he application of the algorithm, but that is
> notably not the case = for std::forward_list. [...]

Surely that's a problem= only for the poor misguided users of std::forward_list. :P

&= gt;=C2=A0The second is about passing std::pair as the argument of the predi= cate for
> erase_if for maps. Yes, from a theoretical POV, passing t= he value_type is
> consistent. Still, IMO, the algorithm should pass= the key and value
> separately, as that allows easier extension to = associative data structures
> that do not store keys and values toge= ther, or not as a std::pair (like e.g.
>=C2=A0http://doc.qt.io/qt-5/qhash.html). It would also= make for easier predicates,
> as they wouldn't need to decompos= e the pair first (no pun intended). Finally,
> it would allow to iso= late such predicates from the unfortunate 'first' and
> '= ;second' names (decomposition declarations solve that, too, but at the = cost of
> another line of code).

Agreed that std::pair has = a pretty terrible API, but for better or worse, it *is* the value_type of t= he container.

> As I _do_ see the value in accepting value_type f= or generic code, how about
> the algorithm checks to see whether it = can pass key and value separately, and,
> if so, does it, otherwise = passes as a pair? Pseudocode:=C2=A0
>
> if constexpr (_= _is_binary_predicate(p)) {
> =C2=A0 =C2=A0 if (p(it->first, it-&g= t;second))
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 it =3D c.erase(it);
>= ; =C2=A0 =C2=A0 else
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ++it;
> } = else {
> =C2=A0 =C2=A0=C2=A0if (p(*it))
> =C2=A0 =C2=A0= =C2=A0 =C2=A0 it =3D c.erase(it);
> =C2=A0 =C2=A0 else
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ++it;
> }

Surely t= he check should be reversed, since breaking down the pair into separate arg= uments is "doing more" than just passing a reference to the pair = itself?
Also, what if 'p' is a generic lambda or somethin= g like that, which is callable in several different ways? Letting th= e algorithm choose the signature with which it'll call 'p' seem= s like a recipe for confusion. Every other algorithm is really explicit abo= ut the exact way it's going to call all its predicate arguments.
<= div>
=E2=80=93Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/e584f516-f714-4175-a4bf-d89cc242cce6= %40isocpp.org.
------=_Part_141_2133372762.1495061994741-- ------=_Part_140_1634515155.1495061994741-- .