220 6967 <52d8d658-8b07-48fe-8990-15133fcc0c53@isocpp.org> article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr-specified loop variable Date: Fri, 4 Oct 2013 11:34:19 -0700 (PDT) Lines: 173 Approved: news@gmane.org Message-ID: <52d8d658-8b07-48fe-8990-15133fcc0c53@isocpp.org> References: <8527db17-8c8a-43c5-b159-4e14c879f774@isocpp.org> <8de4f690-fc62-4058-98fe-87c076d2116e@isocpp.org> <77bb349a-0b9c-4782-af40-b622edda35e8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_214_24200602.1380911659263" X-Trace: ger.gmane.org 1380911657 24676 80.91.229.3 (4 Oct 2013 18:34:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Oct 2013 18:34:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDLTAGNTIBBBK4UXSJAKGQEY6CZ5YQ@isocpp.org Fri Oct 04 20:34:21 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gg0-f199.google.com ([209.85.161.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VSACj-000588-5h for gclcip-std-proposals@m.gmane.org; Fri, 04 Oct 2013 20:34:21 +0200 Original-Received: by mail-gg0-f199.google.com with SMTP id h3sf4270425gge.6 for ; Fri, 04 Oct 2013 11:34:20 -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=bDd0fwIYcxPWgLvlofGm+N8XMEB+iEMZNX0FBL5QDPc=; b=WVuUbFOjEtGg3PHQH/Om9nrLLJVEUWXau6Pxw6ykC7JbwfCONbtnKvawCg/K2Jvn7r +M5IxYP8PYpt+Lvo6wu07oVv0qCnPl9TAFcQieQS5qAv+5IW97WzN7cxoAnNp9LnJQPg SPuoEraVVsn+1U4mqIOW+HlHRtRTY6uRfNpC5vJFPXpWLZeLwWxx7k8Ixb5CY69TqEDp 40Aegxcw5yu9wJUxfF8UKXgCsrmw85QV0sqrSaqKvYbCEGKvJiGC3LuPvDHohwmDxAB4 FogG/6wGhhByAzMdTyYifD7dAiumkFI5FEG2gYfdK4JJh4CptFdRbOSpvzCS32j5I/iR sNwQ== X-Received: by 10.58.56.165 with SMTP id b5mr2483446veq.19.1380911660266; Fri, 04 Oct 2013 11:34:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.104.177 with SMTP id gf17ls1451880qeb.4.gmail; Fri, 04 Oct 2013 11:34:19 -0700 (PDT) X-Received: by 10.49.88.40 with SMTP id bd8mr66031qeb.27.1380911659630; Fri, 04 Oct 2013 11:34:19 -0700 (PDT) In-Reply-To: <77bb349a-0b9c-4782-af40-b622edda35e8@isocpp.org> 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:6967 Archived-At: ------=_Part_214_24200602.1380911659263 Content-Type: text/plain; charset=ISO-8859-1 Using `<>` is probably to drastic, is any language in C family that use them in similar fashion? D even replace them in templates (you write `Type!(A, B)` if you want something like `Type`). On Friday, October 4, 2013 12:01:49 PM UTC+2, Andrew Tomazos wrote: > > On Friday, October 4, 2013 3:05:17 AM UTC+2, Richard Smith wrote: > >> 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. >> > > Ok, if your objections don't come from implementation-difficulty, then I > don't think we are miles apart here: > > How about the following "generic for statement" syntax: > > for > statement > > This expands to: > > template > void __body > { > statement > } > > template > void __repeat_body > { > __body()...; > } > > // callsite > __repeat_body() > > Example usage: > > void f() > { > for > > { > T x = f(0); > T y = x*x; > g(y); > } > > for > h = X::value; > }; > > The main property I am interested in are that the template parameter, > template argument list and inner statement can be defined locally at call > site, without having to manually create two single-use named functions (the > first to accept the template argument list as a parameter pack, the second > to accept the template argument). You want to keep all of it together in > one place, and not have to lexically jump around through names from > different scopes - in the same spirit as a lambda or any statement that has > a sub-statement. > > Discovery should go as usual left-to-range: > > 1. What is the construct `for<` > 2. What is the parameter `template-parameter` > 3. Over what list of things are we varying the parameter `: > template-argument-list` > 4. What are we generating with the parameter: `statement` > > If you don't like the for keyword by all means suggest another syntax, but > I think the problem is worth solving and the semantics of the construct are > worth having. > > Is this closer to something you could get behind? > > -- --- 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_214_24200602.1380911659263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Using `<>` is probably to drastic, is any language i= n C family that use them in similar fashion? D even replace them in templat= es (you write `Type!(A, B)` if you want something like `Type<A, B>`).=

On Friday, October 4, 2013 12:01:49 PM UTC+2, Andrew Tomazos wrote:=
On Friday, Oc= tober 4, 2013 3:05:17 AM UTC+2, Richard Smith wrote:
Tha= t 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 cons= truct: pack expansion. That's the direction that I think should be pursued = here. Plus, any improvements there (such as allowing pack-expansion of expr= ession-statements, or providing pack literals) address a wide variety of pr= oblems and fit nicely with existing language constructs, rather than being = something new and special-purpose.

O= k, if your objections don't come from implementation-difficulty, then I don= 't think we are miles apart here:

How about the following "generic f= or statement" syntax:

    for <template-parameter : template-argument-list&= gt;
        statement

T= his expands to:

&n= bsp;   template<template-parameter>
    v= oid __body
    {
      &= nbsp;   statement
    }

  &nbs= p; template<template-parameter... pack>
    void __= repeat_body
    {
      =   __body<pack>()...;
    }

  =   // callsite
    __repeat_body<template-argument= -list>()

Example usage:

        void f()<= br>        {
    =         for <typename T : int, double= , complex<float>>
       &nb= sp;    {
        =          T x =3D f(0);
 &nb= sp;            =    T y =3D x*x;
       &nbs= p;         g(y);
  &nb= sp;         }

  &n= bsp;         for <int x : 1,2,3&= gt;
           &n= bsp;     h<x> =3D X<x>::value;
 &nb= sp;      };

The main property I am i= nterested in are that the template parameter, template argument list and in= ner statement can be defined locally at call site, without having to manual= ly create two single-use named functions (the first to accept the template = argument list as a parameter pack, the second to accept the template argume= nt).  You want to keep all of it together in one place, and not have t= o lexically jump around through names from different scopes - in the same s= pirit as a lambda or any statement that has a sub-statement.

Discove= ry should go as usual left-to-range:

1. What is the construct `for&l= t;`
2. What is the parameter `template-parameter`
3. Over what list o= f things are we varying the parameter `: template-argument-list`
4. What= are we generating with the parameter: `statement`

If you don't like= the for keyword by all means suggest another syntax, but I think the probl= em is worth solving and the semantics of the construct are worth having.
Is this closer to something you could get behind?

<= /blockquote>

--
 
---
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_214_24200602.1380911659263-- .