220 27742 <54703567-79B1-4BAE-A715-1AB1462D7188@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Matthew Greenwood Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extend the range-based for statement Date: Wed, 10 Aug 2016 10:28:16 +0100 Lines: 309 Approved: news@gmane.org Message-ID: <54703567-79B1-4BAE-A715-1AB1462D7188@gmail.com> References: <152c8499-aa2f-4e23-aeec-cd055f06a6da@isocpp.org> <02cbf744-a192-4bb1-bcb7-d98c3d6464f8@isocpp.org> <2d388706-0c16-4dd6-a3bf-57798da3d5ca@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-BBD74C6F-3F10-46BC-A61A-5AB2CFB7BFC7 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1470821305 5519 195.159.176.226 (10 Aug 2016 09:28:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2016 09:28:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD75FKVW4UGRBNHHVO6QKGQEVEP36BI@isocpp.org Wed Aug 10 11:28:21 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f71.google.com ([74.125.82.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bXPoC-0001Jg-Tb for gclcip-std-proposals@m.gmane.org; Wed, 10 Aug 2016 11:28:20 +0200 Original-Received: by mail-wm0-f71.google.com with SMTP id l4sf53382278wml.0 for ; Wed, 10 Aug 2016 02:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=PzkoNERMwZzrxyXSp6RCoclYl0Q+ti2gYASF2HEy6QU=; b=FXmi+cwtjgWAWCe7ZSZlvhljTAOmJ8kv2afQp2FfqWg0lTDDfIphd4vyGftqPgsDtP mbDkvWLmnnauZdN9xQ3yh7DbSMW/OFxlCT0yBfkquMH/6+L13Rfkrw5frtyQqAm+Ggza Hf80CV5NEYnLqem4AudtQ2NO0nIGqiNHDriFWsfsUXAjCM+ZZEw8ZQBCZOk0KnisYkMh QST2QMKKVWTLm5Ly6c4os7fqfE9ZfyFu7+oePP8QfpnUD3q6WOWg+tFy9j7sj2RCvoTG aOrtLkAPUPbfCqdWE7NjqkhIeNEFcPzoBWtOp3onfX7pAJokiXVJwUuFqAfJDw5NUCSv BtzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:references:in-reply-to:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=PzkoNERMwZzrxyXSp6RCoclYl0Q+ti2gYASF2HEy6QU=; b=iG/qfIvMOmrCdarFYiK6UdbcMhmM1SQ391qFt9abEHNwRf48UZalKp5feU5BEvjDKY QZ2rIg+LtNUynCcTIRotzmurdUcsgmoWxnG7ZYX1GkiX9BUXbQNQvEC1sO7CFZipnz3U Ca6idSTgeI9gUfFP31Utza1ICifze13e06C9GLwzMwWvwcTrt7xSySvkpqGa6dbEC1mM MKbOHRX5RHrAxuLcyK1fVmqFaBK7NBQgXER9vL6Z52LTWf1do0GnMU79kfIWmRPKZJjC tErBx5N3Y+MZ5luU9xRLnPK66/o8tEpti+N/CZfAt4xi+/6C/ukxO1MNuMCYufvAScOt A4G X-Gm-Message-State: AEkoousk0opRar79mxXTF40Du7S/PCyTzsHvGGpJWquNR5V3rCiZzJ//HEEl9l2VFTHPaw== X-Received: by 10.25.42.197 with SMTP id q188mr402567lfq.7.1470821301299; Wed, 10 Aug 2016 02:28:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.165.196 with SMTP id o187ls1165194wme.16.canary; Wed, 10 Aug 2016 02:28:19 -0700 (PDT) X-Received: by 10.28.60.136 with SMTP id j130mr2316509wma.93.1470821299891; Wed, 10 Aug 2016 02:28:19 -0700 (PDT) Original-Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com. [2a00:1450:400c:c09::22f]) by mx.google.com with ESMTPS id t133si7191337wmd.34.2016.08.10.02.28.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Aug 2016 02:28:19 -0700 (PDT) Received-SPF: pass (google.com: domain of matthew.i.greenwood@gmail.com designates 2a00:1450:400c:c09::22f as permitted sender) client-ip=2a00:1450:400c:c09::22f; Original-Received: by mail-wm0-x22f.google.com with SMTP id q128so81383099wma.1 for ; Wed, 10 Aug 2016 02:28:19 -0700 (PDT) X-Received: by 10.194.73.8 with SMTP id h8mr3298010wjv.96.1470821299397; Wed, 10 Aug 2016 02:28:19 -0700 (PDT) Original-Received: from [100.75.79.231] ([213.205.194.83]) by smtp.gmail.com with ESMTPSA id bc10sm42051428wjc.32.2016.08.10.02.28.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 02:28:18 -0700 (PDT) In-Reply-To: <2d388706-0c16-4dd6-a3bf-57798da3d5ca@isocpp.org> X-Mailer: iPhone Mail (13G34) X-Original-Sender: matthew.i.greenwood@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of matthew.i.greenwood@gmail.com designates 2a00:1450:400c:c09::22f as permitted sender) smtp.mailfrom=matthew.i.greenwood@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:27742 Archived-At: --Apple-Mail-BBD74C6F-3F10-46BC-A61A-5AB2CFB7BFC7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree it is not a good idea anymore given the work on the ranges proposal= .. The "min" in my example was for illustration only and I agree other forms o= f iteration are and should be possible. I was not taking personal offence in any way. I was merely trying to say th= at given the proposal was on the list for discussion and that my contact de= tails are in the proposal so that it was possible to have input. I do understand the "skim, delete, never reply" process to emails. I was ju= st stating what I had done to try and get extra feedback. Given the current continuing work in other areas my original proposal is pr= etty much useless. I don't see the point in having multiple ways to do the = same thing. That is just asking for abuse. Also the current library impleme= ntation direction would be much easier, extensible and quicker to get ratif= ied and reduces the need for extra language rules. Also as you point out it= could also be usable by earlier versions of the standard which would negat= e the requirement of rewriting legacy code. On my previous project which inspired the initial proposal all our componen= ts were windows based and communicated through COM so the difference in com= piler was rather agnostic. However, this would have been a limitation to ot= her platforms. The library option is definitely the way to go in my opinion= .. > On 10 Aug 2016, at 06:52, Arthur O'Dwyer wrot= e: >=20 >> On Tuesday, August 9, 2016 at 9:59:27 PM UTC-7, Izzy Coding wrote: >> As the author of the original proposal, other than the discussion refere= nced, I have had no interest from anyone to either champion or help do any = other work to improve the proposal. >> I read that my paper was read and considered, but was not adopted due to= other work being done which would offer similar possibilities (I believe i= t was about the ranges v3). >> My initial argument was that with a relatively simple change we could su= pport looping multiple "ranges" directly in the language rather than making= it a library feature. All the library options could still be usable and so= this proposal would not affect anything. To me combining multiple ranges i= n a wrapper range still feels to me like mixing concerns. >>=20 >=20 > FWIW, I think there's been no interest because the proposal actually isn'= t a good idea. > Like, it's not laziness or cliquishness or personal animosity, it's just = that your proposed feature doesn't sound like a good idea. >=20 > I think Nicol had a very good point when he pointed out that the very ide= a of "iterate over two ranges" conflates two different concerns: there's th= e idea of "how many input ranges do I have", and then separately from that,= there's "how do I aggregate them into something iterable." >=20 > For example, you might want >=20 >> for (auto i =3D 0; i < min(range1.length, range2.length); ++i) >> { >> auto&& item1 =3D range1[i]; >> auto&& item2 =3D range2[i]; >>=20 >> doSomethingWith(item1); >>=20 >> doSomethingRelatedButNotDirectlyConnectedWith(item2); >> } >>=20 >=20 > but then again you might want > for (auto i =3D 0; i < max(range1.length, range2.length); ++i) ... /= / presumably pad the shorter range, whichever it is >=20 > or > for (auto i =3D 0; i < assert_equality(range1.length, range2.length);= ++i) ... >=20 > or >=20 > for (auto i =3D 0; i < sum(range1.length, range2.length); ++i) ... = // presumably concatenate the ranges >=20 >=20 >=20 > The particular way in which you aggregate the two ranges together is actu= ally a very important parametrizable quantity. It's not clear why "min" oug= ht to be privileged with a special language syntax but "max" not be. >=20 >=20 >=20 > But if we let the aggregation function be a parameter, and then we notice= that assert_equality corresponds basically to zip() and sum corresponds ba= sically to concat() and we start filling in missing primitives... well, bef= ore long, we've invented Ranges V3. ;) >=20 >=20 >=20 > So the natural inclination of Committee-folks is probably something like = "Ranges exists and/or is coming; core language changes are hard; this core = language change is both incomplete/asymmetric *and* redundant with Ranges; = so, no." If you think the proposal is good (which, again, I don't, so I th= ink you should drop it), then you're going to have to figure out a way to c= hange folks' minds. >=20 >=20 >=20 > =20 >> I agree this is not the best way to design a system, but lots of us work= ing on real code bases can't always change the legacy code that puts us in = this position. >>=20 >=20 > If you're proposing a core language change, DO NOT use the words "legacy = code". Legacy code by definition can't be rewritten to use C++2w features; = if it could, then you could equally well rewrite it to use Ranges, right no= w. "Legacy code" is the magic phrase you should use when you are defending= AGAINST a core language change (among other situations). See also: auto, s= tatic_assert. >=20 >=20 >> Personally I have always been available for comments and ideas on my pro= posal. Yes I had some personal things going on but I still have not had any= interest at all thus far. Not even from the many people I have emailed it = to. Not even a reply email to say "thanks but no thanks" or whatever. >>=20 >=20 > I'd venture that most software engineers of the caliber that hang out on = this list (probably including yourself) get multiple emails a week =E2=80= =94 from recruiters, or autograph-seekers, or software salespeople, or what= ever =E2=80=94 to which the most socially appropriate response is "skim, de= lete, never reply." After a few years of that routine, some people might c= ome to the opinion that "skim, delete, never reply" is also the most social= ly appropriate response to any kind of unwelcome proposal. Experienced rec= ruiters, salespeople, etc., are conditioned over many years to expect "no r= eply" to 90% of their cold calls. Core-language-feature-proposers might sav= e some of their own sanity by expecting likewise. ;) Life is what it is. >=20 > HTH, > =E2=80=93Arthur > --=20 > You received this message because you are subscribed to a topic in the Go= ogle Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.= org/d/topic/std-proposals/TqfLLDb6DW0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to std-p= roposals+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/isoc= pp.org/d/msgid/std-proposals/2d388706-0c16-4dd6-a3bf-57798da3d5ca%40isocpp.= org. --=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/54703567-79B1-4BAE-A715-1AB1462D7188%40gmail.com= .. --Apple-Mail-BBD74C6F-3F10-46BC-A61A-5AB2CFB7BFC7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree it is not a good idea anym= ore given the work on the ranges proposal.

The "min" in my example was fo= r illustration only and I agree other forms of iteration are and should be = possible.

I was not taking personal offence in any way. I was merely tryi= ng to say that given the proposal was on the list for discussion and that m= y contact details are in the proposal so that it was possible to have input= ..

I do understand the "skim, delete, never reply" process to emails. I wa= s just stating what I had done to try and get extra feedback.

Given the = current continuing work in other areas my original proposal is pretty much = useless. I don't see the point in having multiple ways to do the same thing= .. That is just asking for abuse. Also the current library implementation di= rection would be much easier, extensible and quicker to get ratified and re= duces the need for extra language rules. Also as you point out it could als= o be usable by earlier versions of the standard which would negate the requ= irement of rewriting legacy code.

<= /div>
On my previous project which inspired t= he initial proposal all our components were windows based and communicated = through COM so the difference in compiler was rather agnostic. However, thi= s would have been a limitation to other platforms. The library option is de= finitely the way to go in my opinion.

On 10 Aug 2016, at 06:5= 2, Arthur O'Dwyer <arthur.j= ..odwyer@gmail.com> wrote:

On Tuesday, August 9, 2016 at 9:59:27 PM UTC-7, Izzy Cod= ing wrote:
As the author of the= original proposal, other than the discussion referenced, I have had no int= erest from anyone to either champion or help do any other work to improve t= he proposal.
I read that my paper was read and considered, but was not a= dopted due to other work being done which would offer similar possibilities= (I believe it was about the ranges v3).

My initial argument was that wit= h a relatively simple change we could support looping multiple "ranges" dir= ectly in the language rather than making it a library feature. All the libr= ary options could still be usable and so this proposal would not affect any= thing. To me combining multiple ranges in a wrapper range still feels to me= like mixing concerns.


FWIW, I think th= ere's been no interest because the proposal actually isn't a good idea.
Like, it's not laziness or cliquishness or personal animosity, it's = just that your proposed feature doesn't sound like a good idea.
<= br>
I think Nicol had a very good point when he pointed out that = the very idea of "iterate over two ranges" conflates two different concerns= : there's the idea of "how many input ranges do I have", and then separatel= y from that, there's "how do I aggregate them into something iterable."

For example, you might want

for (auto i =3D 0; i < min(ra= nge1.length, range2.length); ++i)
{
    auto&& item= 1 =3D range1[i];
    auto&& item2 =3D range2[i];

    doSomethingWith(item1);

    doSomethingRelat= edButNotDirectlyConnectedWith(item2);
}


but then again you might want

    for (auto= i =3D 0; i < max(range1.length, range2.length); ++i) ...  // presu= mably pad the shorter range, whichever it is

or

    for (auto i =3D 0; i < assert_equality(range1.len= gth, range2.length); ++i) ...

or

  &n= bsp; for (auto i =3D 0; i < sum(range1.length, range2.length); ++i) ... =   // presumably concatenate the ranges


The partic= ular way in which you aggregate the two ranges together is actually a very = important parametrizable quantity. It's not clear why "min" ought to be pri= vileged with a special language syntax but "max" not be.


B= ut if we let the aggregation function be a parameter, and then we notice th= at assert_equality corresponds basically to zip() and sum corresponds basic= ally to concat() and we start filling in missing primitives... well, before= long, we've invented Ranges V3. ;)


So the natural inclina= tion of Committee-folks is probably something like "Ranges exists and/or is= coming; core language changes are hard; this core language change is both = incomplete/asymmetric *and* redundant with Ranges; so, no."  If you th= ink the proposal is good (which, again, I don't, so I think you should drop= it), then you're going to have to figure out a way to change folks' minds.=


 

I agree this is not the best way to design a system, but lots of= us working on real code bases can't always change the legacy code that put= s us in this position.


If you're propos= ing a core language change, DO NOT use the words "legacy code". Legacy code= by definition can't be rewritten to use C++2w features; if it could, then = you could equally well rewrite it to use Ranges, right now.  "Legacy c= ode" is the magic phrase you should use when you are defending AGAINST a co= re language change (among other situations). See also: auto, static_assert.=


Personally I have always been available for comments and ideas on = my proposal. Yes I had some personal things going on but I still have not h= ad any interest at all thus far. Not even from the many people I have email= ed it to. Not even a reply email to say "thanks but no thanks" or whatever.=



I'd venture that most softw= are engineers of the caliber that hang out on this list (probably including= yourself) get multiple emails a week =E2=80=94 from recruiters, or autogra= ph-seekers, or software salespeople, or whatever =E2=80=94 to which the mos= t socially appropriate response is "skim, delete, never reply."  After= a few years of that routine, some people might come to the opinion that "s= kim, delete, never reply" is also the most socially appropriate response to= any kind of unwelcome proposal.  Experienced recruiters, sales= people, etc., are conditioned over many years to expect "no reply" to 90% o= f their cold calls. Core-language-feature-proposers might save some of thei= r own sanity by expecting likewise. ;)  Life is what it is.
=
HTH,
=E2=80=93Arthur

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.= google.com/a/isocpp.org/d/topic/std-proposals/TqfLLDb6DW0/unsubscribe.<= br> To unsubscribe from this group and all its topics, 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.goo= gle.com/a/isocpp.org/d/msgid/std-proposals/2d388706-0c16-4dd6-a3bf-57798da3= d5ca%40isocpp.org.

--
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.c= om/a/isocpp.org/d/msgid/std-proposals/54703567-79B1-4BAE-A715-1AB1462D7188%= 40gmail.com.
--Apple-Mail-BBD74C6F-3F10-46BC-A61A-5AB2CFB7BFC7-- .