220 33142 <19a415fb-75d2-4a62-9b4e-6a3840c9744d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Bengt Gustafsson 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 04:37:16 -0700 (PDT) Lines: 302 Approved: news@gmane.org Message-ID: <19a415fb-75d2-4a62-9b4e-6a3840c9744d@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> <7909e1f5-68b4-4e73-a7ef-f73e9181bff6@isocpp.org> <42665738-ecdb-4a1f-a2ef-1e466db91b7f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4573_1586989253.1499427437023" X-Trace: blaine.gmane.org 1499427440 5988 195.159.176.226 (7 Jul 2017 11:37:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Jul 2017 11:37:20 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRB3XE7XFAKGQERIUZTEY@isocpp.org Fri Jul 07 13:37:16 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dTRZT-0001Gy-4T for gclcip-std-proposals@m.gmane.org; Fri, 07 Jul 2017 13:37:15 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id c23sf30149840pfe.11 for ; Fri, 07 Jul 2017 04:37:20 -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=fgiK0QZVgwVgrz5RmSRWFC/M/j2Fz1X+WxCrNPgw+4Y=; b=JGst7kFIzZa9aha904Wpe8abp1KNcuwZ/OeeUjD3FiFKpvL9X4ClN3xOn3FN28ru1e mITO6/V3Atnl10KVik2/41d3ZzOAH2LRjbv6pmFgVIkYFL6khErrTUIe65bCtPR5buoh ruPeXxwQIKX6JY5U3PPiUyflIgKAtd+Alw/53qVA8qbE9y7BVO+r+QjVzNy13MXqIYmO /rL9iYSgK5H+GKhzw+Thtm7UoX04oIt84Y47I9/Ik49UgB+8BmWRxHZWf7DD1qJ0xDWT pXGKpTb7TBc2IhdCTC4TsIpFfF3vdVcCQQPXTyyoUSvlWgzv4zSbSjHUHkACJHgP/QSz yKyQ== 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=fgiK0QZVgwVgrz5RmSRWFC/M/j2Fz1X+WxCrNPgw+4Y=; b=hDzpBr7BKoBhHW/DzkvfB4j2DYTblSycIhWHvA70Bixu5UPNIJeZj2rlE5pGzlTbHz hxFJVIl9w5ZFaPUWbOwV4M3Bhha67XEHGiNyhmuldB5ctCW5HmXfqCYUb92qAPXWkgJV nGWYTxV2IW9Z32GjngCze6ZtJeTkpTB85afNE3YKq7BPzgapKdu/m8pDC8L26EQGnHlM Ll/BhatALkGWlVCdF1YpCNL3xF9GPICWhLRmC/GmKfd6xxhD3/x8yO+3UxTbqlM4iLdd SR6LwHkPb04pTfh/CyG+n7Ghk4f1j7BNlRJcRqs4XO6/O8M40VCjVKj6JppqPS63gFRu aRRA== X-Gm-Message-State: AIVw111MZQgWiMFAqjiVeuTxz2Hi7sPdqtygPnXgm/z28v/ZCWaWR3pb zAbLHWHkhUlZ3B4c X-Received: by 10.99.97.69 with SMTP id v66mr1696106pgb.83.1499427439986; Fri, 07 Jul 2017 04:37:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.74.139 with SMTP id k133ls1147772itb.7.canary-gmail; Fri, 07 Jul 2017 04:37:18 -0700 (PDT) X-Received: by 10.36.29.212 with SMTP id 203mr115535itj.5.1499427438132; Fri, 07 Jul 2017 04:37:18 -0700 (PDT) In-Reply-To: <42665738-ecdb-4a1f-a2ef-1e466db91b7f@isocpp.org> X-Original-Sender: bengt.gustafsson@beamways.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:33142 Archived-At: ------=_Part_4573_1586989253.1499427437023 Content-Type: multipart/alternative; boundary="----=_Part_4574_487666174.1499427437024" ------=_Part_4574_487666174.1499427437024 Content-Type: text/plain; charset="UTF-8" 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/19a415fb-75d2-4a62-9b4e-6a3840c9744d%40isocpp.org. ------=_Part_4574_487666174.1499427437024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

Going back to the origi= nal proposal I don't see the point of the
for (1 : 10)<= /span>

version as there is no point in selecting the= loop init value when there is no loop variable to inspect. However, I some= times get into trouble when writing a loop where the loop variable is not n= eeded in the loop body: I get compiler warnings about unused variables. Whi= le 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 possibl= e to allow:

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

but then again a special marker fo= r "the unused 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 c= hange though if it=C2=A0made the most common=C2=A0case the easiest. Somethi= ng 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)
<= div>=C2=A0=C2=A0=C2=A0 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 wro= te:
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, N= icol Bolas wrote:
On Wednesday, July 5, 20= 17 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 possible, a= nd that help ensuring faster and readable coding, at the same time there sh= ould be 0 impact on performance, which should be possible if adding this ex= tension 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 exactl= y as the standard for-loop but much easier to read with such brevity theref= ore less prone to errors. Which was the main reasons for adding the range-f= or to the language after all.

The differen= ce 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. Wha= t 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 langua= ge 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 throu= gh the library.

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

for(auto i: 20rng) {} <= /span>//Counts on the range [0, 20)
for(auto i<= span style=3D"color:rgb(102,102,0)">: 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]
fo= r(auto i: 20rng | 2step) {} //Counts on t= he range [0, 20), in increments of 2
<= /blockquote>

Really, you [ask] us to write this?

I'm sorry, I don't understand what you we= re 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", w= hat's wrong with that?

= Well, "rng" is an abbreviation for "random number generator&= quot;, 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 "revr= ng". 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&= #39;t desire a core language change anymore, because he'd have somethin= g just as useful and in fact infinitely more expressive and flexible, and a= lso he could use it in C++11 today instead of only in C++20 tomorrow.

The point I'm making is not so much tha= t you could do it yourself; after all, you could implement std::vector your= self (except that you can't, but that's another matter), but that&#= 39;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 num= bers more easily, then a library solution would have negligible downsides c= ompared to a language solution. And therefore, the library solution should = be preferred.

Personally, I think this is something the standard lib= rary ought to provide, though the UDL suffixes might be a bit much. But I s= wear by my `_z` suffix; it's absolutely essential for looping over unsi= gned 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/19a415fb-75d2-4a62-9b4e-6a3840c9744d= %40isocpp.org.
------=_Part_4574_487666174.1499427437024-- ------=_Part_4573_1586989253.1499427437023-- .