220 29484 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: for...(T : t) // fold expression improvement Date: Fri, 18 Nov 2016 17:02:39 -0800 Lines: 166 Approved: news@gmane.org Message-ID: References: <7c87350a-7ac2-489b-b107-ea25a7bd6c74@isocpp.org> <110fecc1-a731-f6ad-fa8d-cfe2cb36faaa@gmail.com> <582F2738.7040209@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114dc4b6dec4f605419cfbce X-Trace: blaine.gmane.org 1479517383 2230 195.159.176.226 (19 Nov 2016 01:03:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Nov 2016 01:03:03 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBRGJX3AQKGQEFH4J4KQ@isocpp.org Sat Nov 19 02:02:58 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7u3W-0007ve-HL for gclcip-std-proposals@m.gmane.org; Sat, 19 Nov 2016 02:02:58 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id q13sf171277799vkd.3 for ; Fri, 18 Nov 2016 17:03:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject: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=H7icIohy1bsbIaDUQ/Gr8yhXv6qioPJhUEK1K5NWuZs=; b=Jxyx+u6EwrsVM1D8qulj7kJyMrXuHXXs66/tmyJlEVYlWsDKAFTc4eBjYjsrIomV/R 3lp3RYPWZ3qdYMKi8xi6JbVbCTPdgWm1eceyP8BuU6pZsGShBCI02vqUbqRwrVB+7w8N Hj8Paa4AADKksEMTuOf0R7lE40C+F1SHjhOWjTN1IazVALGtuPxCp9Z5/pb8UcAk6i1o svUq9VJ8abN/VGrVP88SPUy5tYoFbNLgwmqVv8tlr4E8zkPKwTsK5uTLvQXKtu8pDWAE ubhC+qZKLtHpSQMzytIdV6XunKMhQUzq9m4uZELS+mFO43RX2wZvL86olA1jBAXCK7RU O/HQ== X-Gm-Message-State: AKaTC03Aec+ze8uowAcTKGJdRc1uij9Q2619Dv9uHpsUw1qR8CAHIhXF9qVkT5cD7/+/YQ== X-Received: by 10.159.41.69 with SMTP id t63mr698292uat.8.1479517381805; Fri, 18 Nov 2016 17:03:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.58.38 with SMTP id j35ls1663724otc.17.gmail; Fri, 18 Nov 2016 17:03:00 -0800 (PST) X-Received: by 10.31.236.7 with SMTP id k7mr1705945vkh.96.1479517380594; Fri, 18 Nov 2016 17:03:00 -0800 (PST) Original-Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com. [2607:f8b0:400c:c05::22f]) by mx.google.com with ESMTPS id 184si2784995vkb.40.2016.11.18.17.03.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 17:03:00 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::22f as permitted sender) client-ip=2607:f8b0:400c:c05::22f; Original-Received: by mail-vk0-x22f.google.com with SMTP id p9so181259619vkd.3 for ; Fri, 18 Nov 2016 17:03:00 -0800 (PST) X-Received: by 10.31.61.20 with SMTP id k20mr1569250vka.172.1479517379935; Fri, 18 Nov 2016 17:02:59 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.31.199.194 with HTTP; Fri, 18 Nov 2016 17:02:39 -0800 (PST) In-Reply-To: <582F2738.7040209@gmail.com> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c05::22f as permitted sender) smtp.mailfrom=metafoo@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:29484 Archived-At: --001a114dc4b6dec4f605419cfbce Content-Type: text/plain; charset=UTF-8 On 18 November 2016 at 08:07, Matthew Woehlke wrote: > On 2016-11-18 03:36, Ville Voutilainen wrote: > > Alternatively, fold over a lambda: > > > > template > > void foo(T... a) { > > ([&]() { > > std::cout << a << std::endl; > > }(),...); > > } > > Wow... that's twisty :-). I didn't know you could do that with fold > expressions! (That... actually creates a *different lambda* for each > item in `a`!) > > > Caveat emptor, it doesn't work with gcc or msvc yet. > > This version should work: > > template > void foo(T... a) { > ([&](auto&& ai) { > std::cout << ai << std::endl; > }(a),...); > } > > ...and is less surprising that it does ;-). Instead of folding on the > lambda itself, this version folds on invocation of the lambda (albeit a > templated lambda). > I would probably write that as: template void foo(T... a) { auto print = [](auto&& ai) { std::cout << ai << std::endl; }; (print(a), ...); } I find that a bit more readable, especially as it gives a name to the block of code, and as a bonus it avoids unnecessarily creating N different closure types. But I like Ville's approach too :) As an aside, we should probably consider making the parentheses optional when a fold-expression is the sole constituent of an expression-statement. There's no parsing problem I can see with print(a), ...; or std::cout << ... << a; I'd also like to allow a lower-precedence-than-the-operator subexpression on the left or right of a fold-expression, not just a cast-expression. Allowing an equal-precedence operator could also be useful: (std::cout << ... << a.name() << "=" << a.value() << ";") << std::endl; Also, some use cases need a "joiner" between pairs of elements, but at neither the start or the end, which we could support with something like: (std::cout << ... << ", " << ... << a) << std::endl; (expanding to "(std::cout << a$0 << ", " << a$1 << ", " << a$2) << std::endl;"), although maybe that's a little too magical. -- 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/CAOfiQqkrTmvmh8_ei7sg%2BcQcA1G_Sev6rDGn4UjyVBObztRhxw%40mail.gmail.com. --001a114dc4b6dec4f605419cfbce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 8 November 2016 at 08:07, Matthew Woehlke <mwoehlke.floss@gmail.com= > wrote:
On 2016-11-18 03:36, Ville Voutilainen wrote:
> Alternatively, fold over a lambda:
>
> template<typename... T>
> void foo(T... a) {
>=C2=A0 =C2=A0 =C2=A0([&]() {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std::cout << a << std::en= dl;
>=C2=A0 =C2=A0 =C2=A0}(),...);
> }

Wow... that's twisty :-). I didn't know you could do that wi= th fold
expressions! (That... actually creates a *different lambda* for each
item in `a`!)

> Caveat emptor, it doesn't work with gcc or msvc yet.

This version should work:

=C2=A0 template<typename... T>
=C2=A0 void foo(T... a) {
=C2=A0 =C2=A0 =C2=A0 ([&](auto&& ai) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout << ai << std::endl= ;
=C2=A0 =C2=A0 =C2=A0 }(a),...);
=C2=A0 }

....and is less surprising that it does ;-). Instead of folding on the
lambda itself, this version folds on invocation of the lambda (albeit a
templated lambda).

I would probably wri= te that as:

=C2=A0 template= <typename... T>
=C2=A0 void foo(T... a) {
=C2=A0 =C2=A0 =C2=A0 auto print =3D=C2=A0[](auto&= ;& ai) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout << ai &l= t;< std::endl;
=C2=A0 =C2=A0 =C2=A0 };
=C2=A0 =C2=A0 =C2=A0= (print(a), ...);
=C2=A0 }

I find th= at a bit more readable, especially as it gives a name to the block of code,= and as a bonus it avoids unnecessarily creating N different closure types.= But I like Ville's approach too :)

As an asid= e, we should probably consider making the parentheses optional when a fold-= expression is the sole constituent of an expression-statement. There's = no parsing problem I can see with

=C2=A0 print(a),= ...;

or

=C2=A0 std::cout= << ... << a;

I'd also like to all= ow a lower-precedence-than-the-operator subexpression on the left or right = of a fold-expression, not just a cast-expression. Allowing an equal-precede= nce operator could also be useful:

=C2=A0 (std::co= ut << ... << a.name() << &q= uot;=3D" << a.value() << ";") << std::endl= ;

Also, some use cases need a "joiner" b= etween pairs of elements, but at neither the start or the end, which we cou= ld support with something like:

=C2=A0 (std::cout = << ... << ", " << ... << a) << std:= :endl;

(expanding to "(std::cout << a$0= << ", " << a$1 << ", " << a$2)= << std::endl;"), although maybe that's a little too magical= ..

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqkrTmvmh8= _ei7sg%2BcQcA1G_Sev6rDGn4UjyVBObztRhxw%40mail.gmail.com.
--001a114dc4b6dec4f605419cfbce-- .