220 33143 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: Fri, 7 Jul 2017 05:08:50 -0700 (PDT) Lines: 323 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> <42665738-ecdb-4a1f-a2ef-1e466db91b7f@isocpp.org> <19a415fb-75d2-4a62-9b4e-6a3840c9744d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1722_184526921.1499429330418" X-Trace: blaine.gmane.org 1499429335 29460 195.159.176.226 (7 Jul 2017 12:08:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 12:08:55 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBU7T7XFAKGQE45KTQGY@isocpp.org Fri Jul 07 14:08:51 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 1dTS3z-0007FF-U6 for gclcip-std-proposals@m.gmane.org; Fri, 07 Jul 2017 14:08:48 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id o202sf47151936itc.14 for ; Fri, 07 Jul 2017 05:08:53 -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=gClatrHfGxkyTHAIqpWavgR+bI9JioozS3QY0lRXYQ4=; b=mGbS18O9SGZj0NmU2SUMWqjGQp6ID1qssCsOGjM/nzbpoJqbbvHrbPGNrEMlnHxNL4 OPVvB+zQVe2LBq+YxCxvQ7/GZFkC/yP6ZCoarFRGxHzrwwDE2eE0ReESYGXSeK39IkgI +Bxa3L08M5cKxVn5LX1/Kzl2D1CJUGM9GHI6Xd/zq7BuPUzFOVvfz8dtNJJ3PfRCuqbz shMwamG282h6kVxEli1HYxdb8W8LhbIepxxjWXXV6k0jIWRREweTF/DqIiIutQJWqVbm seASw8FoUOIjVnwsVgSiDxE4Ma2GfigBJQCIcgtcPDquOgeuZ4dFmlG1UE+Bg960DRb1 FsYQ== 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=gClatrHfGxkyTHAIqpWavgR+bI9JioozS3QY0lRXYQ4=; b=AEPJ0rTHZKA9vIDcHlmQfSqjNTe2/P42EH30dp/XvuJZAMbaUb//DNamfy2IiCnSz4 XDyYHpTsnBeGgU43uIQ4cS4q2Bz9g8pj0rrJZhYAlEeaVMHqHNOht17BxgnU/Xv6VGo6 TAlwlNpQg44DEkGvAKb99cvQPPf3kNsYS3fzprHmjax/Vs1SQ4XOm0mu2bXBgIOIJYP7 oV7mRdKL8NREdD3n1W6ybRnva+ej0zMFgPyxL74l+qaH36y7nN+GlgQLE9W/ofQiwkkW OPGT2/ylcxgFLR5ioxPJdL+oy2MWBHAFrdjdWLgYXvHPyJlZ9PwoghYLW+MKxyhUl4j0 q0Ew== 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=gClatrHfGxkyTHAIqpWavgR+bI9JioozS3QY0lRXYQ4=; b=KglIyGLUySci89ZyrUkNBh07Hr3bD8nkIoMO4pxjJ+Wqav7cpaEkRhrhzxABxAVEMF GzprjKH8XX1TU0EVRDLIvN0S3FCPEuIuBDSznKtQbmfEOLiTcai6iNDfO4CJ84CWefTa n7/ss1UFxdPaMvefftOTehcC0dqfc1PHrBoiY0ho2s92xwy0z33boTER7ka+9w8TM8Hg 8y1X7jp1/axVVRy47S+Ym37BuLdkBfiOn0Ku1Aa4sBAydSCLMlqovWTw2tUioQsUKMYj MGSiDyaErc8XqW0FGDZD5YmdvgNagPDayFLU6YPPkh0iggYRAH2ujoE0qidG0SrC8sKS nBSQ== X-Gm-Message-State: AIVw1122drNH+q3/GzOlpkGatMPj333FK7wX0atXkrQM/bJXxkmine6A ztRoQh71Ek7qmh7S X-Received: by 10.107.132.129 with SMTP id o1mr1725381ioi.13.1499429332751; Fri, 07 Jul 2017 05:08:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.74.139 with SMTP id k133ls1181765itb.7.canary-gmail; Fri, 07 Jul 2017 05:08:51 -0700 (PDT) X-Received: by 10.36.82.207 with SMTP id d198mr120793itb.8.1499429330996; Fri, 07 Jul 2017 05:08:50 -0700 (PDT) In-Reply-To: <19a415fb-75d2-4a62-9b4e-6a3840c9744d@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:33143 Archived-At: ------=_Part_1722_184526921.1499429330418 Content-Type: multipart/alternative; boundary="----=_Part_1723_934168662.1499429330419" ------=_Part_1723_934168662.1499429330419 Content-Type: text/plain; charset="UTF-8" Maybe I'm reading your post wrong, but t seems to be a pretty rare loop that doesn't need the variable? And why have a : at all in that case, why not? for (v.size()) whatever(); On Friday, July 7, 2017 at 11:37:17 PM UTC+12, Bengt Gustafsson wrote: > > I think this would be a worthwhile extension. The special literal trick > only works for literals but the more important use case is like the example > below where the loop limit is a vector size or some other non constant > value. > > Going back to the original proposal I don't see the point of the > for (1 : 10) > > version as there is no point in selecting the loop init value when there > is no loop variable to inspect. However, I sometimes get into trouble when > writing a loop where the loop variable is not needed in the loop body: I > get compiler warnings about unused variables. While this can be considered > a compiler bug it still has some value to be able to describe that the loop > variable is not needed. Thus it would be possible to allow: > > for (:v.size()) > whatever(); > > but then again a special marker for "the unused varaible" would be more > useful, such as: > > for (auto ? : v.size()) > whatever(); > > > >> I am open to a language change though if it made the most common case the >> easiest. Something like: >> >> for (auto i : v.size()) >> whatever(); >> // Above generate code as if: >> for (decltype(v.size() ) i{0}; i < v.size(); ++i) >> whatever(); >> >> On Thursday, July 6, 2017 at 1:41:34 PM UTC+12, Nicol Bolas wrote: >> >>> 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/eab780da-c6ef-44aa-adc9-606231dfbcb0%40isocpp.org. ------=_Part_1723_934168662.1499429330419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe I'm reading your post wrong, but t seems to= =C2=A0be a pretty rare loop that doesn't need the variable?
A= nd why have a : at all in that case, why not?
for (v.size())=
=C2=A0=C2=A0=C2=A0 whatever();


On Friday, July 7, 2= 017 at 11:37:17 PM UTC+12, Bengt Gustafsson wrote:

I think this would be a worthwhile ex= tension. The special literal trick only works for literals but the more imp= ortant use case is like the example below where the loop limit is a vector = size or some other non constant value.

Going back = to the original proposal I don't see the point of the
for (<= span style=3D"color: rgb(0, 102, 102);">1 :<= span style=3D"color: rgb(0, 0, 0);"> 10)
<= /code>

version as there is no point in selecting the loop init va= lue when there is no loop variable to inspect. However, I sometimes get int= o trouble when writing a loop where the loop variable is not needed in the = loop body: I get compiler warnings about unused variables. While this can b= e considered a compiler bug it still has some value to be able to describe = that the loop variable is not needed. Thus it would be possible to allow:

for (:v.size())
=C2=A0 =C2=A0 whatever();=

but then again a special marker for "the unu= sed varaible" would be more useful, such as:

= for (auto ? : v.size())
=C2=A0 =C2=A0 whatever();

<= /div>
=C2=A0
I=C2=A0am open=C2=A0to a language change though if it=C2=A0made th= e most common=C2=A0case the easiest. Something like:

for (auto i=C2=A0: v.size())
=C2=A0=C2=A0=C2=A0 whatever();
// Above generate code=C2=A0as if:
for (decltype(v.size()= ) i{0};=C2=A0i < v.size(); ++i)
=C2=A0=C2=A0=C2=A0 whatever()= ;

On Thursday, July 6, 2017 at 1:41:34 PM UTC+12, Nicol Bolas= wrote:
On Wednesday, Ju= ly 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 Wednes= day, 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,=C2=A0
Th= anks for your comments.

The idea is to simplify th= e for-loop where it can be possible, and that help ensuring faster and read= able coding, at the same time there should be 0 impact on performance, whic= h 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 gene= rator and generate code that is exactly as the standard for-loop but much e= asier to read with such brevity therefore less prone to errors. Which was t= he 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 th= e 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 desi= red 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<= /span>: 20rng) {} //Counts on the range [0, 20)
for( i: 20revrng) {} //Counts on t= he range (20, 0]
for(auto i: 4begin= | 43end) {}<= span style=3D"color: rgb(0, 0, 0);"> //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 `10r= ng` as shorthand for "an integer range from 0 to 10", what's = wrong with that?

Well, &quo= t;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 r= ight now and write those UDLs himself, and then he wouldn't desi= re a core language change anymore, because he'd have something just as = useful and in fact infinitely more expressive and flexible, and also he cou= ld use it in C++11 today instead of only in C++20 tomorrow.
=

The point I'm making is not so much that you coul= d do it yourself; after all, you could implement std::vector yourself (exce= pt that you can't, but that's another matter), but that's not a= n argument not to have it in the standard library. My main point is that, i= f 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 preferr= ed.

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 integ= ers.

--
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/eab780da-c6ef-44aa-adc9-606231dfbcb0= %40isocpp.org.
------=_Part_1723_934168662.1499429330419-- ------=_Part_1722_184526921.1499429330418-- .