220 33132 <58d87756-f321-4fa4-a2d3-8f694599ed08@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com 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:27:44 -0700 (PDT) Lines: 210 Approved: news@gmane.org Message-ID: <58d87756-f321-4fa4-a2d3-8f694599ed08@isocpp.org> References: <524ec202-94cf-44cf-af4b-ff1339e6f394@isocpp.org> <8cc43aaf-130d-4584-befe-8ace140b7b03@isocpp.org> <181cebac-dd99-477e-adac-823d1a2253f4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3420_419601314.1499293664787" X-Trace: blaine.gmane.org 1499293668 20395 195.159.176.226 (5 Jul 2017 22:27:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2017 22:27:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBYOP6XFAKGQESTHSAXI@isocpp.org Thu Jul 06 00:27:44 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSslp-00050i-Ho for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 00:27:41 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id p135sf161242306ita.11 for ; Wed, 05 Jul 2017 15:27:47 -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=CCD//CBOMJKwnzMiSsuaj2CXloRHlTWt4yTXNl708R8=; b=rQGSaFuUk/pg8PqjUymOgdEO/JMxA+qD7g3dcAhjvri3ryis0WYouy1VYp7tEiBxoQ jLQngFx32BgNcivqF0UDrSphK3O1wGvzJPy2mIEW96gCn1LemqiqBgd038Uz/zrQVd5W uvIx9+KeZ8XvHb3DYPwyPWZCQsdrSoYPu6Q2FXvUSHMMXseaBmqEOXxcK33zczkqzY3K yrugS1lAnMMBKgaRwzyuhScBPYwWO/0WVtnwDpuVU2wRVwalvn1TKH2V6Qr1hFWKMDCv j0DTwC1jHvDHPe3aIgXGggAGjGDw0KolTGqpqhsgL0MBOcaJSwGGRLjQCukunwrTcrUM 37Cw== 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=CCD//CBOMJKwnzMiSsuaj2CXloRHlTWt4yTXNl708R8=; b=WiyC4xfaEleiEKj6c5nwndEB9IKu9OjTG0pnE2p2id9APb5i6BLfFjDhFd2dVnkDWc 5adqt2vt2FmWzmvVvOtFFI/doKi1mcm0LKHZbYLrxB/ASIWAXyxtvf15PWQY3OpfUgCh lLH+fpEBDQS+xOPKlGuC1F72EnK4C2VEfp7OpF8tfSD4EwWGXO2MH1OqWSV2xuqg/i0X MMriH7cFNn7bSGj4NEsAUpRLYSne4GV5he2Nx/Qy2cY8r8MAm8qkXS37Kf0gSbHA1AGx fyd8nNSOfQVv48Vko9tO3WbIEmXbJTYEubaPVpg7Y34PnS9M1OIMtuPAjE3O4/SqnGRl /RIw== 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=CCD//CBOMJKwnzMiSsuaj2CXloRHlTWt4yTXNl708R8=; b=V2AA5YmGnwEugdNZfU4Ud8X9G4MtMMvCb1xEpw+SIQsISw0V9BXGEtY6gGZB99/pLY 4phdr/2HxcVuDLXps/6GVJ+zA7Xdkc6/nvuiCN/KcXeQBdRPGyDrG9Ib4F5Xj2AVR172 63eZDutPct4tRWvOAV5gkX5rHOj3iTkFUsrvr68wO1Gevw7urSZTefC0dlxI2pxZ4yCH VU6hqC7Vt/+KxNFHoWkaKmEs8qby95rSiACrrikkNc5cYmRiyn9v8hBMK69uz4ZayE84 xrOoi27svfADBhcvhOv0m4+hVfbrbHFNPwYkcVClSswimM65PaDyIXLT5oc8IrEsV3s2 JYYw== X-Gm-Message-State: AKS2vOy9T+WubULh+SCTgTSLAqZ3QLG6ec5uBv9CBT1bmeIfuaJ8t/nK yNexcMPI2HFfA8YZ X-Received: by 10.36.39.70 with SMTP id g67mr25189633ita.15.1499293666707; Wed, 05 Jul 2017 15:27:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.67.133 with SMTP id s127ls14113096itb.8.canary-gmail; Wed, 05 Jul 2017 15:27:45 -0700 (PDT) X-Received: by 10.36.125.65 with SMTP id b62mr1312110itc.5.1499293665309; Wed, 05 Jul 2017 15:27:45 -0700 (PDT) In-Reply-To: <181cebac-dd99-477e-adac-823d1a2253f4@isocpp.org> X-Original-Sender: gmisocpp@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:33132 Archived-At: ------=_Part_3420_419601314.1499293664787 Content-Type: multipart/alternative; boundary="----=_Part_3421_2018849127.1499293664788" ------=_Part_3421_2018849127.1499293664788 Content-Type: text/plain; charset="UTF-8" On Thursday, July 6, 2017 at 10:10:26 AM UTC+12, Nicol Bolas wrote: > > 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. > Really, you us to write this? -- 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/58d87756-f321-4fa4-a2d3-8f694599ed08%40isocpp.org. ------=_Part_3421_2018849127.1499293664788 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, July 6, 2017 at 10:10:26 AM UTC+12, N= icol Bolas wrote:
On Wednesday= , July 5, 2017 at 4:36:55 PM UTC-4, Abdulla Herzallah wrote:
HI Nicol Bolas,=C2=A0
Thanks for your co= mments.

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 poss= ible if adding this extension to the range-loop.

A= dding literals support to range-loop is definitely possible "with rela= tive ease" to the compiler syntax parser and code generator and genera= te code that is exactly as the standard for-loop but much easier to read wi= th 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 ge= t the same thing through the library.

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

for(auto i:= 20rng) {} //Counts on= the range [0, 20)
for(auto i: 20revrng) {} <= /span>//Counts on the range (20, 0]<= /span>
for(auto i: 4begin |43end)= {} //Counts= on the range [4, 43)
for(auto<= span style=3D"color: rgb(0, 0, 0);"> i: 16begin | = 12end) {}<= /span> //Counts on the range (16, 12]
for<= span style=3D"color: rgb(102, 102, 0);">(auto i: 20rng 2step)= {} //Counts on the range [0, 20), in incre= ments of 2

Your solution is only useful for co= unting from 0. Oh sure, you can augment it to add more counting types and s= o forth. But that just makes it a more complex feature.

The first two cases you presen= ted does not match the idea as it require use of memory on the stack which = is therefore not good idea.

That's a m= atter for the optimizer to deal with.

While the last example I am not sure I got you w= ell 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 sta= ndard library user-defined literal. `10rng` would, throu= gh 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 br= evity that you can have even with a pure standard library solution.

Really, you us to write this?=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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/58d87756-f321-4fa4-a2d3-8f694599ed08= %40isocpp.org.
------=_Part_3421_2018849127.1499293664788-- ------=_Part_3420_419601314.1499293664787-- .