220 33136 <42665738-ecdb-4a1f-a2ef-1e466db91b7f@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 20:44:55 -0700 (PDT) Lines: 259 Approved: news@gmane.org Message-ID: <42665738-ecdb-4a1f-a2ef-1e466db91b7f@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3542_1008845870.1499312695487" X-Trace: blaine.gmane.org 1499312697 14711 195.159.176.226 (6 Jul 2017 03:44:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Jul 2017 03:44:57 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBOHE63FAKGQEFZEQVSI@isocpp.org Thu Jul 06 05:44:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSxim-0003VI-Fu for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 05:44:52 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id z22sf3948656qka.4 for ; Wed, 05 Jul 2017 20:44:58 -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=rQovIqoT122FbrQBGgV+KdMegnQgmmxBW5MXRUPRgCo=; b=W0RsTT7jl8dSC4FRS0p2cuvbUxnI4lR2LcovzyAUV03MxxsUoYtl/jCJ5vvX22qkd7 D2zIsT8LR8FXMdw9YLEGZ7y04OCK5RvvHTU34OHbOD3+i0HzYJ+X0ggsV8tzhXmPd4c2 08QsdwEUbdP57wG7fqGimJT8GpR2ljt3R20QhUafqL1x0IkS+c5KIGdylVZjR84j8C3C rMZME2XrOHC00ZuDoQdqAxoFwuHgVPlcoKSpXy3jHR3Dd4Ds9Dm+qC0gLMmBcG3sOuCp shXHkfeqGU1/mDg9+OpwiN4whyTy8dU3lR5L0w13kgYlgiwPZH/SAh4LpST06k0Ymd85 7E5A== 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=rQovIqoT122FbrQBGgV+KdMegnQgmmxBW5MXRUPRgCo=; b=Z01UYynjrp5W1zSNEZJp+VE+shLFPLspsGJjThlMgCH5H8yE4wALFfYMtetjQCLIZ9 DE7Cun/+7TKvUAmiZQjPSC3KDyjW55iuJRL/UaYYZlllZRonIDvPFSbNnLbUKeMsmZVD Ie0k5FcTaHKTudL7/K2j3n0V1VeA3i36eyKiuCoUJqKtQM89ctuuLIXrwNe1xaJtvDdg fkwuXzm99WT3OMqKxwSziptJLEgi2uDP5HPEeWEwdePHcC0DNaURtt9HrvbDG5z4j0J3 1b/kLoKS9talCxhOCtEtdg4AYdDXzJufEr7XgsFinkvJk3bXDdJaT5JXkFyKTHG8k6i/ k3TA== 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=rQovIqoT122FbrQBGgV+KdMegnQgmmxBW5MXRUPRgCo=; b=EbgeaOl/j+lNtSYtIPPE2jdpBIyNmXteasjo0i7ZenG2Y4LsLni4mzjLaqQuMd7XXu Xip2hOWeprmGsC2sMITSiZ2R13VeenJfUz+uBgJEMMUW8jyXx/78F8nxEh7zgkZxK2eM aoM+AboINMuCJH1r9x7kIstzU/wGgN4kN+/1pCE+6z2OYhKU5qNy13DEgSnAbx++5rtU 9pr6znzv/6NImIraozpuW5jMqk+TrK4+O3VJA3WVkySJwEBTsP6alWmCRVRLXhhjDICj ZW5gCvIhkQSK8RzzyMdZ3QszABAPbIj8NU11LxvbFVsJgc8JcjFgnygxrQ1M09RPPddA J5mw== X-Gm-Message-State: AIVw113aUrW1UDLKoEC7rhgXnmwOKKdF3jr/xt9ms+HPkvGRFq75/qZY to056Jm4m2QJkG+T X-Received: by 10.237.60.97 with SMTP id u30mr1004195qte.72.1499312697667; Wed, 05 Jul 2017 20:44:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.9.96 with SMTP id j93ls11003363ioi.11.gmail; Wed, 05 Jul 2017 20:44:56 -0700 (PDT) X-Received: by 10.36.29.212 with SMTP id 203mr1095427itj.5.1499312696068; Wed, 05 Jul 2017 20:44:56 -0700 (PDT) In-Reply-To: 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:33136 Archived-At: ------=_Part_3542_1008845870.1499312695487 Content-Type: multipart/alternative; boundary="----=_Part_3543_241611654.1499312695488" ------=_Part_3543_241611654.1499312695488 Content-Type: text/plain; charset="UTF-8" Will the mythical standard library 2 I keep hearing about make std::size_t a signed value? If so, maybe then there is no need for _z? Otherwise, I'm surprised _z isn't in C++17 already. 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/42665738-ecdb-4a1f-a2ef-1e466db91b7f%40isocpp.org. ------=_Part_3543_241611654.1499312695488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Will the mythical standard library=C2= =A02 I keep hearing about make=C2=A0std::size_t a signed value?
I= f so, maybe then there is no need for _z?
Otherwise, I'm surp= rised _z isn't in C++17 already.

I=C2=A0am ope= n=C2=A0to a language change though if it=C2=A0made the most common=C2=A0cas= e the easiest. Something like:

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

On Thu= rsday, 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, Ju= ly 5, 2017 at 4:36:55 PM UTC-4, Abdulla Herzallah wrote:
HI Nicol Bolas,=C2=A0
Thanks for your comm= ents.

The idea is to simplify the for-loop where i= t can be possible, and that help ensuring faster and readable coding, at th= e same time there should be 0 impact on performance, which should be possib= le if adding this extension to the range-loop.

Add= ing literals support to range-loop is definitely possible "with relati= ve 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 fo= r adding the range-for to the language after all.
<= div>
The difference is this: even with a range-ified `std::for_each`, yo= u 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 in= ferior 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 s= uch, 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) {} <= /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

Really, you [ask] us to write this?

= I'm sorry, I don't understand what you were trying to say. If you&#= 39;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 a= n abbreviation for "random number generator", for one. ;)
But I don't think Nicol is [or needs to be] arguing that we should <= i>standardize the UDL suffixes "rng" or "begin" or = "end" or "step" or "revrng". The core point h= ere seems to be [or should be] that Abdulla could go home right now and wri= te those UDLs himself, and then he wouldn't desire a core langua= ge change anymore, because he'd have something just as useful and in fa= ct 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&= #39;t, but that's another matter), but that's not an argument not t= o have it in the standard library. My main point is that, if there is a nee= d for C++ to provide the ability to loop over numbers more easily, then a l= ibrary solution would have negligible downsides compared to a language solu= tion. And therefore, the library solution should be preferred.

Perso= nally, I think this is something the standard library ought to provide, tho= ugh 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 &= 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/42665738-ecdb-4a1f-a2ef-1e466db91b7f= %40isocpp.org.
------=_Part_3543_241611654.1499312695488-- ------=_Part_3542_1008845870.1499312695487-- .