220 33134 <7909e1f5-68b4-4e73-a7ef-f73e9181bff6@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer 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 16:08:01 -0700 (PDT) Lines: 224 Approved: news@gmane.org Message-ID: <7909e1f5-68b4-4e73-a7ef-f73e9181bff6@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3575_389590199.1499296081219" X-Trace: blaine.gmane.org 1499296085 16342 195.159.176.226 (5 Jul 2017 23:08:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2017 23:08:05 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQINFYXVZICRUBF3BKN5Q@isocpp.org Thu Jul 06 01:08:00 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dStOo-0003yp-2b for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 01:07:58 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id x141sf1527137ywg.0 for ; Wed, 05 Jul 2017 16:08:03 -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=EYWLbd5ZhBtWmJXfw23a7+F7fJ9iWDZA1+TJBsmSfPI=; b=o9adTIPF0GtbY7s6BJoDWYEzXcS9QqGRLBN4PPVG+3Awz57AOgaaUn06lQehhCjn2k NzjrhTmPlHvwP8Lr5fHCFF+oA5fYWYL7hkBefhnakqy/Bu9NDMH7Vl0VU4cTKx8Lf1JV oPtth4rEeIfWGsPYQ++6U535HO0xZQ55AOu4I4RSq2u5qnBiehwCjRVxwbJ5yRI5nRzR WO4n18V2olHBm+mxAA/8h7aq3wuUNkYSXKEs/PF/5ZN82pCHotGgIqbGRSnFRo6wgZ+K Q9ljcmbL1IXuVH3q0gBCAGaxew1b7je03Pk4eB7kyzb94bAYMHByTueN0A9BQRuXjuSo 7JiQ== 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=EYWLbd5ZhBtWmJXfw23a7+F7fJ9iWDZA1+TJBsmSfPI=; b=ZENWfFrTYjPU/kZBJ3nmgOJNBrhvt2oqc+y1FmvfY/Ir1sDLe0oCbtLyFU2zpqP73z v80s0BQHg2kVsh7PDbee2hiI5iEq/g7i6qL1rLyriCe6VmL9eT7VqAJ2hI7e0JSixROe wmav1F+rcb3aacY9JHfEsMMPEemCjMP/I5/92OsZBPbF4g7kRJNvzvqRt9gKbtzEYETV m1K9CapmGa5WFMfOJ0nVrfFkbw62tR7rztxTJHAWTcvYT/TXX9vq/aXHhZDiz9dVNgBo mKMDPkgkteErxHPZDkzPo2sMCuT6FF2r4zo/uPhxn28JjFNnbTBNYsh/v1pN3eKfoa8h kYmw== 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=EYWLbd5ZhBtWmJXfw23a7+F7fJ9iWDZA1+TJBsmSfPI=; b=RbceD2WyZvBe2VQLyt96mLS6cc+mGfqqfJ+58Ex1LAArllrb3WL8zfTtrEGgOnIkr0 8T+UA+HNbSwlkUQWv89gCEaayafBgcp7FJfoEeNvG/+wlIli8b15pawuKYtXcxH4UOPL ptn/6LGHLaUmEpSPnj+ZdcEdpeh1vxl8A/KU1grePob//x/T5L/1KY2gpsLb50Fzc+CY UjIIi3mhznufnUgY/doziqvw5/67S1qJW7WmOEUwHbnbp7X8UqR245slbVXWTeqIkX7O izxvMvS7sgtVKKJxHUYFv9FS5QTW9kVtYmdLdhMJvYwtI8xIn/6+Ozju95Smyqp6RfmF YF/Q== X-Gm-Message-State: AIVw1138KJ3OduaQe/BMz9HfoYlT1ElXiTcMHKMK+bcpevIS8ZU29YqE 6pwAkVe3cIgvbegy X-Received: by 10.129.69.21 with SMTP id s21mr46410ywa.92.1499296083153; Wed, 05 Jul 2017 16:08:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.154.139 with SMTP id c133ls1229277ioe.27.gmail; Wed, 05 Jul 2017 16:08:01 -0700 (PDT) X-Received: by 10.36.26.85 with SMTP id 82mr1483578iti.6.1499296081689; Wed, 05 Jul 2017 16:08:01 -0700 (PDT) In-Reply-To: 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:33134 Archived-At: ------=_Part_3575_389590199.1499296081219 Content-Type: multipart/alternative; boundary="----=_Part_3576_1353735132.1499296081219" ------=_Part_3576_1353735132.1499296081219 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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,=20 >>>> Thanks for your comments. >>>> >>>> The idea is to simplify the for-loop where it can be possible, and tha= t=20 >>>> help ensuring faster and readable coding, at the same time there shoul= d be=20 >>>> 0 impact on performance, which should be possible if adding this exten= sion=20 >>>> to the range-loop. >>>> >>>> Adding literals support to range-loop is definitely possible "with=20 >>>> relative ease" to the compiler syntax parser and code generator and=20 >>>> generate code that is exactly as the standard for-loop but much easier= to=20 >>>> read with such brevity therefore less prone to errors. Which was the m= ain=20 >>>> reasons for adding the range-for to the language after all. >>>> >>> >>> The difference is this: even with a range-ified `std::for_each`, you=20 >>> could not get the exact equivalent of range-based `for`, due to having = to=20 >>> pass a functor. What you lose (among other things) is the ability to us= e=20 >>> `break` to terminate the loop early. S a library solution would always = be=20 >>> inferior to the language solution. >>> >>> This is not true of what you're talking about. What I suggested can get= =20 >>> 100% of the desired behavior. As such, there is no *need* to have a=20 >>> 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=20 >>> 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=20 > saying that we shouldn't have something like `10rng` as shorthand for "an= =20 > 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=20 *standardize* the UDL suffixes "rng" or "begin" or "end" or "step" or=20 "revrng". The core point here seems to be [or should be] that Abdulla could= =20 go home right now and write those UDLs *himself*, and then he wouldn't=20 desire a core language change anymore, because he'd have something just as= =20 useful and in fact infinitely more expressive and flexible, and also he=20 could use it in C++11 today instead of only in C++20 tomorrow. Zhihao's reply shows that anyone suitably familiar with C++ can take=20 Nicol's verbal description of "10rng" and turn it into working, zero-cost= =20 C++ code. I notice that Zhihao implemented the much more conservative=20 syntax xrange(10), presumably by analogy with Python. I like this. :) =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/7909e1f5-68b4-4e73-a7ef-f73e9181bff6%40isocpp.or= g. ------=_Part_3576_1353735132.1499296081219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, July 5, 2017 at 3:41:21 PM UTC-7, Nicol Bola= s wrote:
On We= dnesday, July 5, 2017 at 6:27:44 PM UTC-4, gmis...@gmail.com wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
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,=C2=A0
Thanks fo= r your comments.

The idea is to simplify the for-l= oop where it can be possible, and that help ensuring faster and readable co= ding, at the same time there should be 0 impact on performance, which shoul= d 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 a= nd generate code that is exactly as the standard for-loop but much easier t= o 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::fo= r_each`, you could not get the exact equivalent of range-based `for`, due t= o having to pass a functor. What you lose (among other things) is the abili= ty to use `break` to terminate the loop early. S a library solution would a= lways 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 beh= avior. 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:<= /span> 4begin | = 43end) {} //Counts on the range [4, 43)
for= (auto i: 16begin | 12end) {} //Counts on t= he range (16, 12]
for= (auto i: 20rng<= /span> | 2step) {} //Counts on the range [0, 20), in increments of 2

Really, you [as= k] us to write this?

I'm sorry, I don&= #39;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 &q= uot;random number generator", for one. ;)
But I don't th= ink Nicol is [or needs to be] arguing that we should standardize the= UDL suffixes "rng" or "begin" or "end" or &q= uot;step" or "revrng". The core point here seems to be [or s= hould be] that Abdulla could go home right now and write those UDLs hims= elf, and then he wouldn't desire a core language change anymore, be= cause he'd have something just as useful and in fact infinitely more ex= pressive and flexible, and also he could use it in C++11 today instead of o= nly in C++20 tomorrow.

Zhihao's reply show= s that anyone suitably familiar with C++ can take Nicol's verbal descri= ption of "10rng" and turn it into working, zero-cost C++ code. I = notice that Zhihao implemented the much more conservative syntax xrange(10), presumably by analogy with P= ython. I like this. :)

=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/7909e1f5-68b4-4e73-a7ef-f73e9181bff6= %40isocpp.org.
------=_Part_3576_1353735132.1499296081219-- ------=_Part_3575_389590199.1499296081219-- .