220 14491 article Path: news.gmane.org!not-for-mail From: Brent Friedman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Range-based if Date: Tue, 11 Nov 2014 15:12:10 -0600 Lines: 113 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1134f86e890bc205079bbbde X-Trace: ger.gmane.org 1415740340 20309 80.91.229.3 (11 Nov 2014 21:12:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 21:12:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHLPXGUXMJBBK7XRGRQKGQETDS25LY@isocpp.org Tue Nov 11 22:12:13 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XoIjV-0003To-2v for gclcip-std-proposals@m.gmane.org; Tue, 11 Nov 2014 22:12:13 +0100 Original-Received: by mail-pd0-f197.google.com with SMTP id fp1sf59904168pdb.4 for ; Tue, 11 Nov 2014 13:12:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=MOIxRbKLxisM2Uumy0l0JzD25cU4KvzPBsW2ffIe0pY=; b=KiwLigc2RJBHWVqeP68rRIXW/P0jRBqeJE23CIR8NVUAxiBMku0cCXV1b31c9lzO3E nriEXahrgFpHwpm5YtsnaY6H0gggDLXs5AuchIyB/u3nTnUAqo7rSZvNO0yKuN7XXfuI EDW98IxA3IL22jpE4g3Z4Q9GeVcZt76WUeUl7LjLkf2+SvtpmcAU9YKOFmybH9dXu+q7 y6JbAcQYTz28nZRQTsmkAi2qQQZNYT8WkROngq0NL2UGt1JqiMqQ4P3+ILeTXKrY7xxZ zR1p6TD2GO9QIAUaXnam5/AOWoatw+rUUsP6QXjhzslZOU5bA3t9VXx+VJEuaapw6VeH KC0A== X-Gm-Message-State: ALoCoQkcCbofL3mlKSaCv0cIaJ2UFKWajTFFGTc2fpXBsfEdC6yUjU/UXy3HCHqajjW6YZ21T9KD X-Received: by 10.70.19.201 with SMTP id h9mr32639537pde.3.1415740332195; Tue, 11 Nov 2014 13:12:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.84.162 with SMTP id a2ls851230obz.73.gmail; Tue, 11 Nov 2014 13:12:11 -0800 (PST) X-Received: by 10.60.245.99 with SMTP id xn3mr35208963oec.15.1415740331399; Tue, 11 Nov 2014 13:12:11 -0800 (PST) Original-Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com. [2607:f8b0:4003:c01::235]) by mx.google.com with ESMTPS id y10si25223584obs.12.2014.11.11.13.12.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Nov 2014 13:12:11 -0800 (PST) Received-SPF: pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:4003:c01::235 as permitted sender) client-ip=2607:f8b0:4003:c01::235; Original-Received: by mail-ob0-f181.google.com with SMTP id uy5so7932509obc.26 for ; Tue, 11 Nov 2014 13:12:11 -0800 (PST) X-Received: by 10.202.198.82 with SMTP id w79mr32821052oif.45.1415740331197; Tue, 11 Nov 2014 13:12:11 -0800 (PST) Original-Received: by 10.202.232.77 with HTTP; Tue, 11 Nov 2014 13:12:10 -0800 (PST) X-Original-Sender: fourthgeek@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:4003:c01::235 as permitted sender) smtp.mail=fourthgeek@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:14491 Archived-At: --001a1134f86e890bc205079bbbde Content-Type: text/plain; charset=UTF-8 I've noted in our codebase that we lean heavily on the convenience of range-based for even when it's not perhaps the best way to express an idea. //do something to the first item for (auto& Item : range) { DoSomething(Item); break; } This pattern leads not only to some clarity problems, but also to unreachable code warnings (for the loop increment statement) on various compilers. Range-for is the best way to work with ranges currently but doesn't very well handle when you only want to operate on the first element of the range. Our immediate solutions would be something like if (range.begin() != range.end()) { auto&& Item = *range.begin(); DoSomething(Item); } This is particularly inconvenient compared to range-for and it either means evaluating begin() twice or declaring an extra variable for begin(). An algorithmic sibling to for_each could be added, std::for_front( range, DoSomething); This brings with it some of the inconveniences and optimization issues experienced of the std algorithm approach. It seems to me that a range-based if, or some similar control structure, could help here. //do something to the first item if (auto& Item : range) { DoSomething(Item); } this would be expanded similar to { auto&& __range = range_expr; auto&& __begin = __range.begin(); if (__begin != __range.end()) { auto& Item = *__begin; // your code here } } -- --- 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 email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a1134f86e890bc205079bbbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've noted in our codebase that we lean heavily on the= convenience of range-based for even when it's not perhaps the best way= to express an idea.

//do something to the first item
for (auto& Item : range)
{
=C2=A0 =C2=A0 Do= Something(Item);
=C2=A0 =C2=A0 break;
}

<= /div>
This pattern leads not only to some clarity problems, but also to= unreachable code warnings (for the loop increment statement) on various co= mpilers. Range-for is the best way to work with ranges currently but doesn&= #39;t very well handle when you only want to operate on the first element o= f the range.

Our immediate solutions would be some= thing like
if (range.begin() !=3D range.end())
{
<= div>=C2=A0 =C2=A0 auto&& Item =3D *range.begin();
=C2=A0 = =C2=A0 DoSomething(Item);
}

This is part= icularly inconvenient compared to range-for and it either means evaluating = begin() twice or declaring an extra variable for begin().

An algorithmic sibling to for_each could be added,
std::f= or_front( range, DoSomething);=C2=A0

This brings w= ith it some of the inconveniences and optimization issues experienced of th= e std algorithm approach.

It seems to me that a ra= nge-based if, or some similar control structure, could help here.
//do something to the first item
if (auto& Item : range)
{
=C2=A0 =C2=A0 DoSomething(Item);
}
<= br>
this would be expanded similar to
{
=C2= =A0 =C2=A0auto&& __range =3D range_expr;
=C2=A0 =C2=A0aut= o&& __begin =3D __range.begin();
=C2=A0 =C2=A0if (__begin= !=3D __range.end())
=C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2= =A0auto& Item =3D *__begin;
=C2=A0 =C2=A0 =C2=A0// your code = here
=C2=A0 =C2=A0}
}

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--001a1134f86e890bc205079bbbde-- .