220 33131 <181cebac-dd99-477e-adac-823d1a2253f4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?Q?=5Bstd=2Dproposals=5D_Re=3A_Proposal_to_extend_range=2Dbased_?= =?UTF-8?Q?=E2=80=98for=E2=80=99_loop_example=3A__for=281=3A10=29?= Date: Wed, 5 Jul 2017 15:10:25 -0700 (PDT) Lines: 210 Approved: news@gmane.org Message-ID: <181cebac-dd99-477e-adac-823d1a2253f4@isocpp.org> References: <524ec202-94cf-44cf-af4b-ff1339e6f394@isocpp.org> <8cc43aaf-130d-4584-befe-8ace140b7b03@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3646_1620859210.1499292625831" X-Trace: blaine.gmane.org 1499292641 24225 195.159.176.226 (5 Jul 2017 22:10:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2017 22:10:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBUWH6XFAKGQE6PLZIPI@isocpp.org Thu Jul 06 00:10:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSsV4-0005Mp-Nn for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 00:10:22 +0200 Original-Received: by mail-ua0-f198.google.com with SMTP id 46sf746984uai.11 for ; Wed, 05 Jul 2017 15:10:28 -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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=sB/zA4ZF+COSCS8hHgTyuHyrej9pWLeLAaF4/3vZDoU=; b=j6AqfevIOEvAln9M/JCwRx29u8rkTZojCy9k4N4gmMK+QgEfxYEELVAIZt0wqrhME8 9PLHgr+G4ADvd9MrDUrQg92JCOdpEAnqqHZHMduwDJQ2eU4KUusb3vhhx+ezH5lRni31 AARQOEY3qGsU/+iWUhNIUJMbQ3RCwoiqU20+EsYgu/Z++PYhNC1KA4Ux3+C/90PI4aMt mTn86Czt7LYtE4yK+j+zbLi25FG1S2Nw4YKNJnEB0l3BY3cddvy2zoZjLLbYFnYAL5a0 B8qUXnJFsScZa78U7KZGiN3CqEAxGnQ1r7OJG/vSRq+D2GsReKY7D7nBGDtrvDR7i9Tn qN/Q== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=sB/zA4ZF+COSCS8hHgTyuHyrej9pWLeLAaF4/3vZDoU=; b=bqZknAKPpANfHHljKST3tCDpwPC12tuFI4ybMUHEO6MEj/BDdgO5rTC649rObSMgfF 2n3521CKyO4q5g7EpazX6VTNeAyoT0o0gRl4U1aT5NQWgEXTWuPlIvcZL4suQoCWhJYS nM9Dd6i1+BsqvOqFN8sHS9SY8K1MYzBYnd8qWqhBeqQ3+tqFpFhtAXJwmkrEu+7DWy3c PlZGQf0KLw6OgTYVEjgkvKKSD0U/SFLL8oSMvq1llOBDK9Vt8DYVq5XsD1OQlQqR1X2V F/ykmBROIbf2YRfw6sIetFfmUzCEHdfwUA9fkepOgPyYdokSajZ42faDfC+02aNOM26b K9/A== 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=sB/zA4ZF+COSCS8hHgTyuHyrej9pWLeLAaF4/3vZDoU=; b=ngWQiOFTC6ogjXb3S+97mf/AR4KXwVAwpXIbv83JyfAIJGR5xTXBvIpkV+ONC3q/aY 15znm/JGgfGbuGAepjtvtuLHODXghheoRdkgHeJJY5wNOYlEFBK3m1v6v6o+wNVY773Q GVqQWUXhQLtFXx4Nq48M2kWh4yOaZe7hBeyiiHkpkCp/YIMyoqLvwdWHxGghh0by13Sn MABIJbSsOj/MFx2J0Su2+T7PLqYL35aVL8rqKzqyxRBd/K8HNlnKG5r0Edis/nZalHso MEYU3x/E43znfMcQuFhr9zTapZC64HohEYh3EVdHeq8AcC+cRy18Eq9dH7fL98Nl2Q17 FhKw== X-Gm-Message-State: AIVw110glp9ZVCL8aXo3sYrSHsPbCgPaGd4+eBy921R3SbKWkiJFqOfR rmGSB+JICCCmjE9k X-Received: by 10.31.139.197 with SMTP id n188mr53858vkd.11.1499292627748; Wed, 05 Jul 2017 15:10:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.143.88 with SMTP id r85ls10664819iod.5.gmail; Wed, 05 Jul 2017 15:10:26 -0700 (PDT) X-Received: by 10.36.3.81 with SMTP id e78mr929557ite.9.1499292626341; Wed, 05 Jul 2017 15:10:26 -0700 (PDT) In-Reply-To: <8cc43aaf-130d-4584-befe-8ace140b7b03@isocpp.org> X-Original-Sender: jmckesson@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:33131 Archived-At: ------=_Part_3646_1620859210.1499292625831 Content-Type: multipart/alternative; boundary="----=_Part_3647_707179951.1499292625831" ------=_Part_3647_707179951.1499292625831 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 5, 2017 at 4:36:55 PM UTC-4, Abdulla Herzallah wrote: > > HI Nicol Bolas, > Thanks for your comments. > > The idea is to simplify the for-loop where it can be possible, and that > help ensuring faster and readable coding, at the same time there should be > 0 impact on performance, which should be possible if adding this extension > to the range-loop. > > Adding literals support to range-loop is definitely possible "with > relative ease" to the compiler syntax parser and code generator and > generate code that is exactly as the standard for-loop but much easier to > read with such brevity therefore less prone to errors. Which was the main > reasons for adding the range-for to the language after all. > The difference is this: even with a range-ified `std::for_each`, you could not get the exact equivalent of range-based `for`, due to having to pass a functor. What you lose (among other things) is the ability to use `break` to terminate the loop early. S a library solution would always be inferior to the language solution. This is not true of what you're talking about. What I suggested can get 100% of the desired behavior. As such, there is no *need* to have a language solution, since we can get the same thing through the library. Not only that, we can do so much better with a library-based solution: for(auto i: 20rng) {} //Counts on the range [0, 20) for(auto i: 20revrng) {} //Counts on the range (20, 0] for(auto i: 4begin | 43end) {} //Counts on the range [4, 43) for(auto i: 16begin | 12end) {} //Counts on the range (16, 12] for(auto i: 20rng | 2step) {} //Counts on the range [0, 20), in increments of 2 Your solution is only useful for counting from 0. Oh sure, you can augment it to add more counting types and so forth. But that just makes it a more complex feature. The first two cases you presented does not match the idea as it require use > of memory on the stack which is therefore not good idea. > That's a matter for the optimizer to deal with. While the last example I am not sure I got you well on it, but it seems is > what I am proposing in a different way, but none the less is still not > possible without adding this feature to the language. > No, I was talking about having a standard library user-defined literal . `10rng` would, through a UDL function, invoke `std::ints(10)`. Nothing in the language needs to be changed to make that happen. I used that as an example of the brevity that you can have even with a pure standard library solution. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/181cebac-dd99-477e-adac-823d1a2253f4%40isocpp.org. ------=_Part_3647_707179951.1499292625831 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, July 5, 2017 at 4:36:55 PM UTC-4, Abdulla He= rzallah wrote:
HI Nicol Bolas,=C2=A0
Thanks for your comments.

The idea is to simplify the for-loop where it can be possible, and that = help ensuring faster and readable coding, at the same time there should be = 0 impact on performance, which should be possible if adding this extension = to the range-loop.

Adding literals support to rang= e-loop is definitely possible "with relative ease" to the compile= r syntax parser and code generator and generate code that is exactly as the= standard for-loop but much easier to read with such brevity therefore less= prone to errors. Which was the main reasons for adding the range-for to th= e language after all.

The difference is th= is: even with a range-ified `std::for_each`, you could not get the exact eq= uivalent of range-based `for`, due to having to pass a functor. What you lo= se (among other things) is the ability to use `break` to terminate the loop= early. S a library solution would always be inferior to the language solut= ion.

This is not true of what you're talking about. What I sugge= sted can get 100% of the desired behavior. As such, there is no need= to have a language solution, since we can get the same thing through the l= ibrary.

Not only that, we can do so much better with a library-based= solution:

for(auto i: 20rng) {} //= Counts on the range [0, 20)
for(auto<= /span> i: 20revrng) {} //Counts on the range (20, 0]
for(au= to i: 4begin | 43end) {} //Counts on the range [4, 43= )
for(auto i: 16begin = | <= span style=3D"color: #066;" class=3D"styled-by-prettify">12end) {} //Counts on the range (16, 12]
for(auto i: = 20rng | 2step) {} //Counts on th= e range [0, 20), in increments of 2

Your solut= ion is only useful for counting from 0. Oh sure, you can augment it to add = more counting types and so forth. But that just makes it a more complex fea= ture.

The first two cases you presented does not match the idea as it = require use of memory on the stack which is therefore not good idea.
<= /div>

That's a matter for the optimizer to deal wi= th.

While the last example I am not sure I got you well on it, but it = seems is what I am proposing in a different way, but none the less is still= not possible without adding this feature to the language.
<= /blockquote>

No, I was talking about having a standard library user-defined= literal. `10rng` would, through a UDL function, invoke `std::ints(10)`= .. Nothing in the language needs to be changed to make that happen.

I= used that as an example of the brevity that you can have even with a pure = standard library solution.

--
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/181cebac-dd99-477e-adac-823d1a2253f4= %40isocpp.org.
------=_Part_3647_707179951.1499292625831-- ------=_Part_3646_1620859210.1499292625831-- .