220 33135 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 18:41:34 -0700 (PDT) Lines: 220 Approved: news@gmane.org Message-ID: References: <524ec202-94cf-44cf-af4b-ff1339e6f394@isocpp.org> <8cc43aaf-130d-4584-befe-8ace140b7b03@isocpp.org> <181cebac-dd99-477e-adac-823d1a2253f4@isocpp.org> <58d87756-f321-4fa4-a2d3-8f694599ed08@isocpp.org> <7909e1f5-68b4-4e73-a7ef-f73e9181bff6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3567_958051180.1499305294087" X-Trace: blaine.gmane.org 1499305299 3962 195.159.176.226 (6 Jul 2017 01:41:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 01:41:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTVK63FAKGQEK2Z5IMQ@isocpp.org Thu Jul 06 03:41:34 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSvnP-0000e7-3b for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 03:41:31 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id o202sf168880755itc.14 for ; Wed, 05 Jul 2017 18:41:36 -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=JiQkViQ2MZcA+U1INYCBUZccAFE4p/TmJcCvdLylI58=; b=v1FeXlG1oq8v1syYuFDtSZ5JxiWDG4YD9JjhjR/rdniy7OCGRjr5/hsqb6iJFSu2St QEI3l0Rov2rLwJYgv/n1b+QAItoxmyUyF1xtLA541w0Akgp3hjucjtionLe1h/GhvOdW lIK049bYOTPDrYRDHVShMdnjpZtTtZHSh+4xZhKuKNmsHcJq8evCRbivC03vEprsurPG HKNWE9p7k3Z1qKk7rV/joMVWJ7eDy/0Kuv/z5txh33JuCbkFR2zv3x04LIHlyuuH2Wh3 9WtuTMObQYd0ZeRQaRDLjalgvkENLYfBjRCJUcabf2pkyW+gKZJkdyy/5n+hD4q1tzDD dyQw== 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=JiQkViQ2MZcA+U1INYCBUZccAFE4p/TmJcCvdLylI58=; b=AlJ8gVGhb7gv2tH3U2xDvGHg+wALe6VFB20rMEDzEBM6382x6iBL0W3O3C71rqAPgK flaArr85+n4oiOUYZZGTwghxALaXv+R1pIhrFmHSeyyvbydUtQZCHeDf3dqwIHtx0wpx FsH8UTvMCT0ZXsL856DcrQ0WGv0YUy5SscJ1cF2lnCaHV4t3BtAX+rXdUZOupKRYznel 2AgQkXQEgjkLeErsm5CE5kD2rVBwoxaDJMw/o+6F0dSEClZ/OTETimBairnapcgXtC80 S2kJNEqBwEFaldoPUyl9wNoszv9wrjDfc/9LS8FJ/YCSUIeuAaXXYpA0SowHSP31e+P0 pHpQ== 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=JiQkViQ2MZcA+U1INYCBUZccAFE4p/TmJcCvdLylI58=; b=LySdD//DRBLMFACecMK47RuxbWu4aq3I1iwxKwK+lBhp5q7sRjtEPmawqRPuCdehRn bm03I/HK3LC7E1Paw7olcRCWeNQRIxAZy5SlzL+1cYLN3gwWDXZxUA8txc5rvQ4C1l2M zCTBFSIYR7XPQezpbl9hUfbQXLFTdRebEZsvrHPt0s/3fTMf9S43n/vMoBKHtjGlPETn owCL1VYDD16R5WeiwgXYpWH+gTXf3b9thUJiqFGkGzBwMDSR6WVUM1uYj5UhfJ/Mz8J1 0PQ5ZvS2nq0KGbLZ5GGLEaPDeBhX16VHCEuKsnLxPANuIgafzt+03xzIp3mwXkMGgott l5nQ== X-Gm-Message-State: AIVw113VaHvawewjxJxtr9UQYrKot8raYFwrkDigmY85469ScyPT5szL 8qzHIJYqbuc9OPJo X-Received: by 10.107.141.69 with SMTP id p66mr773920iod.44.1499305296191; Wed, 05 Jul 2017 18:41:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.181.22 with SMTP id e22ls9908681iof.47.gmail; Wed, 05 Jul 2017 18:41:34 -0700 (PDT) X-Received: by 10.36.19.1 with SMTP id 1mr1560174itz.4.1499305294619; Wed, 05 Jul 2017 18:41:34 -0700 (PDT) In-Reply-To: <7909e1f5-68b4-4e73-a7ef-f73e9181bff6@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:33135 Archived-At: ------=_Part_3567_958051180.1499305294087 Content-Type: multipart/alternative; boundary="----=_Part_3568_1506435451.1499305294087" ------=_Part_3568_1506435451.1499305294087 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 5, 2017 at 7:08:01 PM UTC-4, Arthur O'Dwyer wrote: > > On Wednesday, July 5, 2017 at 3:41:21 PM UTC-7, Nicol Bolas wrote: >> >> On Wednesday, July 5, 2017 at 6:27:44 PM UTC-4, gmis...@gmail.com wrote: >>> >>> 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 >>>> >>> >>> Really, you [ask] us to write this? >>> >> >> I'm sorry, I don't understand what you were trying to say. If you're >> saying that we shouldn't have something like `10rng` as shorthand for "an >> integer range from 0 to 10", what's wrong with that? >> > > Well, "rng" is an abbreviation for "random number generator", for one. ;) > But I don't think Nicol is [or needs to be] arguing that we should > *standardize* the UDL suffixes "rng" or "begin" or "end" or "step" or > "revrng". The core point here seems to be [or should be] that Abdulla could > go home right now and write those UDLs *himself*, and then he wouldn't > desire a core language change anymore, because he'd have something just as > useful and in fact infinitely more expressive and flexible, and also he > could use it in C++11 today instead of only in C++20 tomorrow. > The point I'm making is not so much that you could do it yourself; after all, you could implement std::vector yourself (except that you can't, but that's another matter), but that's not an argument not to have it in the standard library. My main point is that, if there is a need for C++ to provide the ability to loop over numbers more easily, then a library solution would have negligible downsides compared to a language solution. And therefore, the library solution should be preferred. Personally, I think this is something the standard library ought to provide, though the UDL suffixes might be a bit much. But I swear by my `_z` suffix; it's absolutely essential for looping over unsigned integers. -- 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/c9137815-ef08-4816-9423-bb27b98ccb11%40isocpp.org. ------=_Part_3568_1506435451.1499305294087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, July 5, 2017 at 7:08:01 PM UTC-4, Arthur O&#= 39;Dwyer wrote:
On Wednesday, July 5, 2017 at 3:41:21 PM UTC-7, Nicol Bolas wrote:
On Wednesday, July 5, 201= 7 at 6:27:44 PM UTC-4, gmis...@gmail.com wrote:
On Thursday, July 6, 2017 at 10:10:26 A= M UTC+12, Nicol 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 comments.
=

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

Adding literal= s support to range-loop is definitely possible "with relative ease&quo= t; 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 brevi= ty therefore less prone to errors. Which was the main reasons for adding th= e 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 fun= ctor. What you lose (among other things) is the ability to use `break` to t= erminate the loop early. S a library solution would always be inferior to t= he language solution.

This is not true of what you're talking ab= out. 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 th= ing through the library.

Not only that, we can do so much better wit= h 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(<= span style=3D"color:rgb(0,0,136)">auto i: 4begin | 43end) {}<= /span> //Counts on the range [4, 43)
for(auto i: 16begin | 12end) {} //Counts on the range (16, 12]
for(auto i: <= /span>20rng | 2step<= /span>) {} //Counts o= n the range [0, 20), in increments of 2

Really, you [ask] us to write this?

I'm sorry, I don't understand what you= were trying to say. If you're saying that we shouldn't have someth= ing like `10rng` as shorthand for "an integer range from 0 to 10"= , what's wrong with that?

Well, "rng" is an abbreviation for "random number generat= or", for one. ;)
But I don't think Nicol is [or needs to= be] arguing that we should standardize the UDL suffixes "rng&q= uot; or "begin" or "end" or "step" or "r= evrng". The core point here seems to be [or should be] that Abdulla co= uld go home right now and write those UDLs himself, and then he woul= dn't desire a core language change anymore, because he'd have somet= hing just as useful and in fact infinitely more expressive and flexible, an= d also he could use it in C++11 today instead of only in C++20 tomorrow.

The point I'm making is not so much = that you could do it yourself; after all, you could implement std::vector y= ourself (except that you can't, but that's another matter), but tha= t's not an argument not to have it in the standard library. My main poi= nt is that, if there is a need for C++ to provide the ability to loop over = numbers more easily, then a library solution would have negligible downside= s compared to a language solution. And therefore, the library solution shou= ld be preferred.

Personally, I think this is something the standard = library ought to provide, though the UDL suffixes might be a bit much. But = I swear by my `_z` suffix; it's absolutely essential for looping over u= nsigned integers.

--
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/c9137815-ef08-4816-9423-bb27b98ccb11= %40isocpp.org.
------=_Part_3568_1506435451.1499305294087-- ------=_Part_3567_958051180.1499305294087-- .