220 6936 article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: constexpr-specified loop variable Date: Thu, 3 Oct 2013 13:15:30 -0700 (PDT) Lines: 171 Approved: news@gmane.org Message-ID: References: <8527db17-8c8a-43c5-b159-4e14c879f774@isocpp.org> <9982d18b-ef8d-4538-a1d7-2e7e2f02aecb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_110_27159961.1380831330914" X-Trace: ger.gmane.org 1380831330 11249 80.91.229.3 (3 Oct 2013 20:15:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Oct 2013 20:15:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDLTAGNTIBBBZFAW6JAKGQERAFS5EA@isocpp.org Thu Oct 03 22:15:35 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VRpJ8-0000Pl-JM for gclcip-std-proposals@m.gmane.org; Thu, 03 Oct 2013 22:15:34 +0200 Original-Received: by mail-ie0-f197.google.com with SMTP id u16sf9860925iet.0 for ; Thu, 03 Oct 2013 13:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=/A+p5iuIyPugAwlV/eZVcpQ7vry3nl/Fl34VcTRQNns=; b=T1KIqa72j+rkzt63yQ3nluJ3/sG72K7R633JmEOgrIfYGuIvm4UlQ5UZuSp9T6O88D 7idthFeoik+BXTtRph9rakm1RRJ6/3JaI8r8fw6zWz1zEl8zQ0OXA2zEOFQ2WFWhMZ+1 t8x/Wx5SrzM0HdF8KxmHlrM9hcyU7O+GS4MbF2CdEPoEmNjD0nY76ImQBXrkNikHAQpo PZpvK9dVebMmQJxRIQq8biXXMaKhn82v/HXHyOnCLkDxNhhgqKk9hkLXFIMeR313Yr8n C8/ZwY+fejd5WjlaDDFBX98GT4R9osfj4QJfDVDuwjmpaEsCdsy2hNJO6kHvnrToYCG6 p47g== X-Received: by 10.42.37.143 with SMTP id y15mr5239690icd.26.1380831333563; Thu, 03 Oct 2013 13:15:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.109.194 with SMTP id hu2ls695365igb.36.gmail; Thu, 03 Oct 2013 13:15:32 -0700 (PDT) X-Received: by 10.50.62.20 with SMTP id u20mr218951igr.11.1380831332311; Thu, 03 Oct 2013 13:15:32 -0700 (PDT) In-Reply-To: X-Original-Sender: inkwizytoryankes@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:6936 Archived-At: ------=_Part_110_27159961.1380831330914 Content-Type: text/plain; charset=ISO-8859-1 Yes, it should have scope, and will not break switch because switch allow loops (and scopes) inside: http://en.wikipedia.org/wiki/Duff%27s_device (and it should work in C++ at least in g++ it still works). On Thursday, October 3, 2013 9:31:02 PM UTC+2, Alex B wrote: > > > On Thu, Oct 3, 2013 at 2:38 PM, Andrew Tomazos > > wrote: > >> I would suggest extending unrolled for statements to allow the typedefspecifier and a type-init-list (a braced-init-list of type-ids): >> >> template >> void func() >> { >> for (typedef T : {Args...}) >> g(); >> } >> >> The semantics are clear. The declaration at the start of each block >> becomes a typedef of the corresponding type. >> > > Maybe "using" instead of "typedef"? Usually, what follow typedef is the > name of the original type, not the alias. > *typedef *int *T*; > *using T* = int; // closer to what you want > > Also, having a list of types delimited by {} is a bit weird and it might > be complicated to make it work... > > >> Another important thing it need to ignore `break` and `continue`. >>> >> >> I think break and continue should have their usual expected semantics. >> break jumps to the end of the last unrolled block. continue jumps to >> the start of the next one. >> >> >> > This is require to allow integrate with normal loops or switch >> statement: >> >>> switch(i) >>> { >>> for...(Ti : T) >>> { >>> case Ti::value: >>> Ti::f(); >>> break; //break for `switch` not `for...` >>> } >>> } >>> >>> >> > I think I looked at that sample too quickly; I agree as well that break > and continue should not have special rules. Your "for..." should really > behave like a regular "for" in term of scope as well. That debate is going > in the same direction as the "static if" debate: should it introduce a new > scope? Consensus so far is: definitely. > > Of course, that would break the switch example... > -- --- 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/. ------=_Part_110_27159961.1380831330914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, it should have scope, and will not break switch becau= se switch allow loops (and scopes) inside: http://en.wikipedia.org/wiki/Duf= f%27s_device (and it should work in C++ at least in g++ it still works).

On Thursday, October 3, 2013 9:31:02 PM UTC+2, Alex B wrote:

On Thu, Oct 3, 2013 at 2:38 PM, Andrew Tomazos <andrew...@gmail.com> wrote:
I would suggest extending unrolled for statements to allow th= e typedef specifier and a ty= pe-init-list (a braced-init-list of type-ids):

    template<typename... Args>
 = ;   void func()
    {
   &nbs= p;    for (typedef T : {Args...})
    = ;        g<T>();
  &n= bsp; }

The semantics are clear.  The declaration at the start o= f each block becomes a typedef of the corresponding type.

Maybe "using" instead of "type= def"? Usually, what follow typedef is the name of the original type, not th= e alias.
typedef int= T;
using T =3D int; // close= r to what you want

Also, having a list of t= ypes delimited by {} is a bit weird and it might be complicated to make it = work...


Another important thing it need to ignore `break` and `con= tinue`.

I think break and continue should have their usual expected semant= ics.  break j= umps to the end of the last unrolled block.  continue jumps to the start of the next one= ..

 
> This is require to allow integrate with normal loops or= switch statement:
switch(i)
{
    for...(Ti = : T)
    {
  &n= bsp; case Ti::value:
        Ti::f()= ;
        break; //break for `switch` not `for...`
    }
}



I think I looked at that sample too quickly; I agree as well that break and= continue should not have special rules. Your "for..." should really behave= like a regular "for" in term of scope as well. That debate is going in the= same direction as the "static if" debate: should it introduce a new scope?= Consensus so far is: definitely.

Of course, that would break the switch example...
=

--
 
---
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>.
------=_Part_110_27159961.1380831330914-- .