220 33133 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 15:41:21 -0700 (PDT) Lines: 216 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_230_445535826.1499294481124" X-Trace: blaine.gmane.org 1499294487 10217 195.159.176.226 (5 Jul 2017 22:41:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Jul 2017 22:41:27 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBEOW6XFAKGQEPUXOE6A@isocpp.org Thu Jul 06 00:41:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dSsz0-0002DQ-6P for gclcip-std-proposals@m.gmane.org; Thu, 06 Jul 2017 00:41:18 +0200 Original-Received: by mail-pf0-f199.google.com with SMTP id c23sf2991501pfe.11 for ; Wed, 05 Jul 2017 15:41:23 -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=609wSfN3D2ZUdwIhxZUgqYbS44eIKvSjazr7jjX5dKo=; b=pE4qBr5oxszeeMNWeuyKlEhpDvy9QxODChZVUoFmpIOZ+jU4jEHAOYuEldXyw/wlBv 9gjbEpSd9o8avnLvyCZl7c+5vCMHQHcSSOeoRcYD/axIkZkazCXFNyy6ToeAeBOf4KEm gVALjvYKA8Mt3GGs67qFIcV81vrxHDQJuSISjKFHdov84DuVQENH6hD/i3N0PSGqI4cj 2+Kqw1AQAHEIKnWOA7nDTx70VR5DwIF9CQu1EApyPt0vVaZkZETZwjRZQSahPEW8zsiT LtaD8h3BwmKizEyLnxggvejp1zZrWOoyAMGrmX9Cs/qLmATcCBX3r6dgy9uZbiXgsDKl QIvw== 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=609wSfN3D2ZUdwIhxZUgqYbS44eIKvSjazr7jjX5dKo=; b=kL3+WQpD1SFhwVsWWxhjuHWgsllKyzJCaiU/NosDt7dJgcSZ9O+56Kox5KDcm8Dcp3 E5wIxNRxlS+FpWDHpPIWuSZZLazCJBeROLiPZ/n1dIcBayRZ2Hf/08V3MHPrK5B22Wsh NkgwHT7lV7yUmFPS7Q8W5OjUQgJTxzpxeUE9E50tsYNoPOtCxpxyiiqLSfrNmO35xCyr nAMUZ/fZ9KBuUd4TncyzLsK6t9xqcEq3Fp9c7qKPUiEvBU+H6d0P+SsCWc/qw2WWHCPj QxwYuK1EfzFkEKTCyxpTqUaoSV+Vs7pcb45buj6oaZLGNGUYlOtFlIP0/NLVzQ9Vyw5G 55mw== 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=609wSfN3D2ZUdwIhxZUgqYbS44eIKvSjazr7jjX5dKo=; b=J7TZY0k8G2Y2h6A14o7EM3xMf5pZNZ/iURW+JrMV0CaUf1y0StSNf4NYZR17BWRwjU +wxChVu1KJy0g8nly8K1T8srOCcdJQcIfx8VYLSsgH3bdY7r+7guPMi4Nhga/D7+ZF+7 ExRhJtiTvMvDl7fie9b3EGK+vsb3X46S9eqJGcC7526QEHmL4zTMNTLffrfYKJxawVFM pvfgLLc7yfqtGzpe42VjRedkbzW5HGg4Flr/XukjubUGTVlfNBcpSj3i2/315sHabm1S ovOzVQESmtP+nr3147ijeGlnuN9B/0LCujE8nYf9aqzLzfYpmEUyXCBgG5UWRluEV/YA XSDQ== X-Gm-Message-State: AIVw113T6c4ekhiqAIjEcJcGLNJIjYRFrWrdN1mRFmATlmNwevaggAEF GwjTYPgDNXJ8pQCD X-Received: by 10.99.36.135 with SMTP id k129mr387272pgk.134.1499294483161; Wed, 05 Jul 2017 15:41:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.29.194 with SMTP id 185ls7862291itj.17.gmail; Wed, 05 Jul 2017 15:41:21 -0700 (PDT) X-Received: by 10.36.80.193 with SMTP id m184mr454099itb.6.1499294481720; Wed, 05 Jul 2017 15:41:21 -0700 (PDT) In-Reply-To: <58d87756-f321-4fa4-a2d3-8f694599ed08@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:33133 Archived-At: ------=_Part_230_445535826.1499294481124 Content-Type: multipart/alternative; boundary="----=_Part_231_629319472.1499294481124" ------=_Part_231_629319472.1499294481124 Content-Type: text/plain; charset="UTF-8" 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 >> >> Your solution is only useful for counting from 0. Oh sure, you can >> augment it to add more counting types and so forth. But that just makes it >> a more complex feature. >> >> The first two cases you presented does not match the idea as it require >>> use of memory on the stack which is therefore not good idea. >>> >> >> That's a matter for the optimizer to deal with. >> >> While the last example I am not sure I got you well on it, but it seems >>> is what I am proposing in a different way, but none the less is still not >>> possible without adding this feature to the language. >>> >> >> No, I was talking about having a standard library user-defined literal >> . `10rng` would, >> through a UDL function, invoke `std::ints(10)`. Nothing in the language >> needs to be changed to make that happen. >> >> I used that as an example of the brevity that you can have even with a >> pure standard library solution. >> > > Really, you 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? -- 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/c8c4a3e3-fdb5-4bf1-b62f-ae32a6c3882e%40isocpp.org. ------=_Part_231_629319472.1499294481124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, July 5, 2017 at 6:27:44 PM UTC-4, gmis...@gm= ail.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
Thanks for your comments.

The idea is t= o simplify the for-loop where it can be possible, and that help ensuring fa= ster and readable coding, at the same time there should be 0 impact on perf= ormance, which should be possible if adding this extension to the range-loo= p.

Adding literals support to range-loop is defini= tely possible "with relative ease" to the compiler syntax parser = and code generator and generate code that is exactly as the standard for-lo= op 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 rang= e-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 libr= ary 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 langu= age solution, since we can get the same thing through the library.

N= ot only that, we can do so much better with a library-based solution:
for(auto= i: 20rng) {} //Counts on the range [0, 20)
for(aut= o i: 20revrng= ) {} //Counts on the range (20, 0]
for(auto i: 4begin <= /span>| 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 increment= s of 2

Your solution is only useful for counti= ng from 0. Oh sure, you can augment it to add more counting types and so fo= rth. But that just makes it a more complex feature.

The first two cases you presented does not mat= ch the idea as it require use of memory on the stack which is therefore not= good idea.

That's a matter for the op= timizer to deal with.

= While the last example I am not sure I got you well on it, but it seems is = what I am proposing in a different way, but none the less is still not poss= ible without adding this feature to the language.

No, I was talking about having a standard library = user-defined literal. `10rng` would, through a UDL function, invoke `st= d::ints(10)`. Nothing in the language needs to be changed to make that happ= en.

I used that as an example of the brevity that you can have even = with a pure standard library solution.

Really, you us to write this?

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

--
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/c8c4a3e3-fdb5-4bf1-b62f-ae32a6c3882e= %40isocpp.org.
------=_Part_231_629319472.1499294481124-- ------=_Part_230_445535826.1499294481124-- .