220 6941 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr-specified loop variable Date: Thu, 3 Oct 2013 18:05:17 -0700 Lines: 188 Approved: news@gmane.org Message-ID: References: <8527db17-8c8a-43c5-b159-4e14c879f774@isocpp.org> <8de4f690-fc62-4058-98fe-87c076d2116e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b07205a51af3804e7dfe5dc X-Trace: ger.gmane.org 1380848718 28459 80.91.229.3 (4 Oct 2013 01:05:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Oct 2013 01:05:18 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBTVIXCJAKGQEM36ZHWY@isocpp.org Fri Oct 04 03:05:20 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VRtpY-00053W-6K for gclcip-std-proposals@m.gmane.org; Fri, 04 Oct 2013 03:05:20 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id i3sf731699oag.10 for ; Thu, 03 Oct 2013 18:05:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=pO+gvBrZehafGzRzT8quhBHDbF4470y/YKMb9bHac5I=; b=HKmPIFVubW8xkFIfFn3uut+rAUcymQ9A1XFMt2ZC1ydw6NTN6dMvKm9KOQTTf/aGLb 4DrIYbBTj/IPivL13nUhxIRDiTXT8/2pnjFfzkLf1/kY+kDUYgLpO7/lLYwHvOY5jG2f 9KlOk4HaHUuHOMgkrQB1blBThfsy8KXWHMzggjduX+qfWRnKKuaRKnzNy41SxRIfLiGB PVzvn8gyQVbTAieZSbQjoyfIyYdQc0gJ6ATdBqZerZp0iPLmuW8rJBLS0JxpPAM62iSp 6aXxdQzyyiTd/HBIvnhty/FM83/94gsl7bYPcSwzjiqdeF9iz/yFJ4lj/NByOICFBaoy 5ZjQ== X-Received: by 10.50.109.193 with SMTP id hu1mr3689111igb.6.1380848719147; Thu, 03 Oct 2013 18:05:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.67.48 with SMTP id k16ls855279igt.40.gmail; Thu, 03 Oct 2013 18:05:18 -0700 (PDT) X-Received: by 10.68.218.163 with SMTP id ph3mr11452676pbc.19.1380848718084; Thu, 03 Oct 2013 18:05:18 -0700 (PDT) Original-Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [2607:f8b0:400e:c02::230]) by mx.google.com with ESMTPS id zv1si7360120pbc.247.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 18:05:18 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400e:c02::230 as permitted sender) client-ip=2607:f8b0:400e:c02::230; Original-Received: by mail-pd0-f176.google.com with SMTP id q10so3201209pdj.7 for ; Thu, 03 Oct 2013 18:05:18 -0700 (PDT) X-Received: by 10.68.115.15 with SMTP id jk15mr11624766pbb.36.1380848717899; Thu, 03 Oct 2013 18:05:17 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.70.43.145 with HTTP; Thu, 3 Oct 2013 18:05:17 -0700 (PDT) In-Reply-To: <8de4f690-fc62-4058-98fe-87c076d2116e@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400e:c02::230 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:6941 Archived-At: --047d7b07205a51af3804e7dfe5dc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 3, 2013 at 5:20 PM, Andrew Tomazos wrote: > On Friday, October 4, 2013 1:17:06 AM UTC+2, Richard Smith wrote: > >> On Thu, Oct 3, 2013 at 3:56 PM, Andrew Tomazos wrote: >> >>> Yes, as per my followup to Daniel I meant that it isn't effectively >>> possible because of how range-based for is currently defined. >>> >> >> It's *not* effectively impossible. To reiterate: you can pick a range >> type such that the code is valid. It's just not very useful. >> > > Yes, fine. We are in violent agreement that a constexpr-specified loop > variable is currently impossible to use in a very useful way. > > The purpose isn't to force unrolling, the term "unrolled" is purely for >>> specification purposes. An implementation is free to unroll a normal loop, >>> and is free to rollup an "unrolled" loop. It's purely the logical >>> behaviour of the program that is specified. >>> >> >> No, this is something different. You want the static types of elements of >> the loop body to be different on different iterations, for instance. That >> *forces* the loop to be fully unrolled. >> > > In some cases, such as when there are varying static types dependant on > the loop variable it may force the loop to be unrolled, but this would be a > consequence of the intention of the code, and not grounds to claim the > construct is unintuitive. > It's a consequence of the new semantics you'd be giving to the construct, so this is a property of the construct itself, not of the code using it. > We can think of the inner statement of the unrolled for statement as if it >>> were the body of a unnamed template function, >>> >> >> Right. Making it act like a template is the thing that's new and >> unintuitive. >> > > I think you may be conflating the unintuitive with the > difficult-to-implement. > I was addressing this thread from the point of view of a user of C++, but speaking now as a compiler implementer, I disagree. I don't *want* to implement this, because I think it's a bad syntax, but it's not really difficult, just weird, surprising, non-uniform, and inelegant. The argument for this particular syntax seems to basically be "there's a hole in the grammar here which we can jam something new into" rather than "this is a natural extension of the existing syntax". That's a bad argument. Using the "constexpr" keyword to mean "implicitly treat the body of this loop like it's a template" is new and unintuitive. That said, I think the problem is worth solving. And we already have a tool to repeatedly stamp out multiple, slightly different, copies of the same construct: pack expansion. That's the direction that I think should be pursued here. Plus, any improvements there (such as allowing pack-expansion of expression-statements, or providing pack literals) address a wide variety of problems and fit nicely with existing language constructs, rather than being something new and special-purpose. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b07205a51af3804e7dfe5dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 3, 2013 at 5:20 PM, Andrew Tomazos <a= ndrewtomazos@gmail.com> wrote:
=
On Friday, October 4, 2013 1:17:06 AM UTC= +2, Richard Smith wrote:
On Thu, Oct 3, 2013 at 3:56 PM, Andrew To= mazos <andrew...@gmail.com> wrote:
Yes, as per my followup to Daniel I meant that it isn't effectively pos= sible because of how range-based for is currently defined.

It's *not* effectively imp= ossible. To reiterate: you can pick a range type such that the code is vali= d. It's just not very useful.
=A0
Yes, fine.=A0 We are in violent agreement that a constexp= r-specified loop variable is currently impossible to use in a very useful w= ay.

The purpose isn't to force = unrolling, the term "unrolled" is purely for specification purpos= es.=A0 An implementation is free to unroll a normal loop, and is free to ro= llup an "unrolled" loop.=A0 It's purely the logical behaviour= of the program that is specified.

No, this is something differen= t. You want the static types of elements of the loop body to be different o= n different iterations, for instance. That *forces* the loop to be fully un= rolled.
=
In some cases, such as when there are varying static types dependant on= the loop variable it may force the loop to be unrolled, but this would be = a consequence of the intention of the code, and not grounds to claim the co= nstruct is unintuitive.

It's a consequence of the new se= mantics you'd be giving to the construct, so this is a property of the = construct itself, not of the code using it.
=A0
We can think of the inner state= ment of the unrolled for statement as if it were the body of a unnamed temp= late function,

Right. Making it act like a template is the thing that&= #39;s new and unintuitive.
=A0
I think you may be conflating the unintuit= ive with the difficult-to-implement.

I was addressing this thread from the point of view of a user of C++,= but speaking now as a compiler implementer, I disagree. I don't *want*= to implement this, because I think it's a bad syntax, but it's not= really difficult, just weird, surprising, non-uniform, and inelegant.

The argument for this particular syntax seems to basica= lly be "there's a hole in the grammar here which we can jam someth= ing new into" rather than "this is a natural extension of the exi= sting syntax". That's a bad argument. Using the "constexpr&qu= ot; keyword to mean "implicitly treat the body of this loop like it= 9;s a template" is new and unintuitive.

That said, I think the problem is worth solving. And we= already have a tool to repeatedly stamp out multiple, slightly different, = copies of the same construct: pack expansion. That's the direction that= I think should be pursued here. Plus, any improvements there (such as allo= wing pack-expansion of expression-statements, or providing pack literals) a= ddress a wide variety of problems and fit nicely with existing language con= structs, rather than being something new and special-purpose.

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b07205a51af3804e7dfe5dc-- .