220 26305 <6b2c3588-e67e-4a8b-94d6-bdacd50ac244@isocpp.org> article Path: news.gmane.org!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: statement folding on variadic templates parameters pack Date: Sun, 12 Jun 2016 16:52:03 -0700 (PDT) Lines: 463 Approved: news@gmane.org Message-ID: <6b2c3588-e67e-4a8b-94d6-bdacd50ac244@isocpp.org> References: <1e3daa7c-e10a-4589-8118-26f47bc1a0df@isocpp.org> <2d8458f8-27b2-464f-a16e-fc866ccfd2cd@isocpp.org> <8dc1e665-42a3-4ef0-a2d2-3773afab170c@isocpp.org> <20160612153937.4898897.23968.12102@gmail.com> <57d8c679-f312-4b77-8210-705f5e093b7e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_493_10668978.1465775523272" X-Trace: ger.gmane.org 1465775534 30792 80.91.229.3 (12 Jun 2016 23:52:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2016 23:52:14 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBJHL665AKGQET4M3DKQ@isocpp.org Mon Jun 13 01:52:08 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bCFAk-0006Ma-Rn for gclcip-std-proposals@m.gmane.org; Mon, 13 Jun 2016 01:52:07 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id d2sf72924583iof.3 for ; Sun, 12 Jun 2016 16:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HAOels+femTfJEHh85ordxb45j1/5HchEXVJHgyd378=; b=eir1jVIfwCJ68KtDkstlvQ6latCKtBpHj7UsTOScW/PmU/ktvtGAj2keuIQp8fXyEc +1Ks/xQhNsgKtQQre67o16zMn4wGz8HijUxC0vp7GOfMWkzc1PpsFp2YBRte+mobL4UB BSgP2TdsMnRHKht3pW46pK2qJfH/Roxl/T+DV7hNKrYShAkYnDxK/mbnDcFyE3daIzx/ qDvctaokzDkt15pS5S8ttfIIYYTxmvjyX/wJs0THeLlggSqsoEfc0dQU7N+25QPUJt1F Lg4BesRS46sSedXZqurmQQGlhjEHhxBIWKPq/JlQ43rRMtjja8BM1BB7/6h+G5CMwvm9 0NZA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HAOels+femTfJEHh85ordxb45j1/5HchEXVJHgyd378=; b=bDgWzEj6WliFtUi6Pyl8Tia7fsFyJlDXkEjCa8z7PMMDTUCrfaOPSW+NYDDm0ShTY9 4mRDXYanGJNBUaV5sX5cKkwPX2v/BZJa1SXdKFBe5YovuR+5RFu0nJ1V5WCXQl2rzo5H NFIfpUcd8kxGOxxTjR+3cwcZV4XP3l2RZyHTrpchyxotDxVcCI4dB06/nYCDPpcoFSnA 4Jo35BzcajjLC53ETlqMgnZ2mkvgvwRCsqVsydJQxUn+GzULp/oyjYALCUnli774d5pP aQMV7LwiC3kO6xeYA99cK+mKrN57jkAwkn4i3VT9kT0ryKukmYIaj+rXF1yxDyNV8O9d VwUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=HAOels+femTfJEHh85ordxb45j1/5HchEXVJHgyd378=; b=SYt68kExGOQcSnNkFgpdX0R33urISXe1OrnrFah2VAbfGaifr0KqMnZ8UE7Y6OYASI BRTowHuR9CBVERnUCJHObXgQlbHSJNiUyDw8I3WlJ27KmBy0D4z55WdUSDepwyzgs2N+ bv0ru8duddwr6j+uZ4H+UbNEhRIudzmYw4tzD2oC61wtJG2yv9QkURPA/uPo1v5u5ip7 0CW40iuxcHkSuhOECS0aLVL9UcQP2TyGfmReBIsbKL0kryH4L8pEC5MOwFgmYeq/IjMk Z7fsb9X3lRWjw/XsTuk+gjrt4iPMi/tJspXbgz2VuPZCe8G8NtPIbRJ3mhVGlE6aniAm UbUw== X-Gm-Message-State: ALyK8tKsTbDzF5eZJ30SWtSbR6wNEfKkyDHahKb0JhidnlsqtLIEve6KBof4L9mUbocjrg== X-Received: by 10.107.143.12 with SMTP id r12mr2893323iod.9.1465775525851; Sun, 12 Jun 2016 16:52:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.36.85 with SMTP id f82ls861141ita.33.canary; Sun, 12 Jun 2016 16:52:04 -0700 (PDT) X-Received: by 10.36.249.140 with SMTP id l134mr37499ith.9.1465775524561; Sun, 12 Jun 2016 16:52:04 -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-Spam-Checked-In-Group: std-proposals@isocpp.org 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:26305 Archived-At: ------=_Part_493_10668978.1465775523272 Content-Type: multipart/alternative; boundary="----=_Part_494_1328588024.1465775523274" ------=_Part_494_1328588024.1465775523274 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, June 12, 2016 at 9:32:22 PM UTC+2, Arthur O'Dwyer wrote: > > On Sun, Jun 12, 2016 at 10:22 AM, >= =20 > wrote: > >> On Sunday, June 12, 2016 at 5:39:41 PM UTC+2, Tony V E wrote: >> > How do I break from the for constexpr, if 'break' doesn't do it? >> >> >> `break` work same as in normal `for`, critical is last `break` in=20 >> original `switch` because `for constexpr` breaks there. I skip one=20 >> transformation stage that show it: >> switch (x) >> { >> case Op0::OpId: Op0::OpFunc(); goto finalFor; >> case Op1::OpId: Op1::OpFunc(); goto finalFor; >> case Op2::OpId: Op2::OpFunc(); goto finalFor; >> case Op3::OpId: Op3::OpFunc(); goto finalFor; >> finalFor: break; >> } >> > > No, that doesn't work. I think Tony has a point. > Sergey's half-proposal wants to make "break" and "continue" inside a "for= =20 > constexpr" act exactly like "break" and "continue" inside a non-constexpr= =20 > "for": > > for constexpr(typename T : Ts...) { > do_something(); > if constexpr(is_same_v) break; > } > > This code would generate an unrolled loop of do_something()s for each = T=20 > in Ts... up to and including the first instance of nullptr_t. As soon as= =20 > it generated do_something(), it would break and stop iterating= =20 > over Ts.... > > You can't have break work this way (Sergey's way) and also have it work= =20 > for outer switch statements; you have to pick one. And I think you've=20 > picked the wrong one, for two reasons: > > First, Ed Catmur has shown that if what you really want is a way to=20 > pack-expand switch cases, there might be more natural syntaxes to express= =20 > that. > > // Natively (this syntax strikes me as ungraceful, I admit) > switch (x) { > case Op::OpId: { Op::OpFunc(); break; }... > } > > I start from that syntax and after that I switch to `for constexpr` because= =20 it was for me lot more readable and have more usages. =20 > // Or via some sort of library template > auto switch_ =3D make_switch( > make_switch_case( Op::OpId, [](){ return Op::OpFunc(); } )... > ); > auto result =3D switch_.on(x) + switch_.on(y); > > template > auto switch_on(X&& x, Cs&&... cases) { > return=20 > make_switch(std::forward(cases)...).on(std::forward(x)); > } > > But it would be hard to generate code from it that will be comparable with= =20 native `switch`. =20 > Second, I think you're doing the same thing I did at first, which is to= =20 > treat "for constexpr" (or whatever) as a pack-expansion primitive in the= =20 > same vein as fold-expressions, whereas what it really wants to be is a=20 > compile-time control-flow (code-generation) primitive in the same vein as= =20 > "if constexpr" and function templates. If you stop thinking of it as=20 > physically duplicating/unrolling its contents (the way a fold-expression= =20 > does), then you no longer have to worry about what unrolling a "break" or= =20 > "continue" statement would mean. > > I found the docs for Boost.Switch=20 > . If I get the= =20 > time, I'll try to write up a modern library implementation of the above= =20 > make_switch and post it here. I'm sure it's been done before, of course,= =20 > so if someone beats me to it that's great. > > =E2=80=93Arthur > One question how will work this code? switch (0) { for (;;) { f(); case 0: g(); break; } h(); } It will call `g` and then `h` because `break` is from `for` not from=20 `switch`. Now with `for constexpr`: switch (0) { for constexpr (int I : II...) { f() case I: g(); break; } h(); } It will call `g<0>` and then `h`. Exactly same as for normal `for`. Only=20 change is how `case` is handled. Overall I assume that `for constexpr` will conceptually "unroll" body for= =20 each parameter pack element. This is need because each "iteration" body can= =20 be completely different: for constexpr (typename T : TT...) { T x; //this will require creating separate variable for each iteration,= =20 but they lifetime not overlap. } Probably only real difference is when some iteration could create invalid= =20 code. In my approach it will always be invalid, in case of "dynamic"=20 control-flow it can be valid if `for` leave early. I think It could be possible to tweak both approach to have same output=20 based on reachability of each iteration body. If is unreachable it will be= =20 not generated. Adding `case` will made all iteration reachable and=20 generated. --=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/6b2c3588-e67e-4a8b-94d6-bdacd50ac244%40isocpp.or= g. ------=_Part_494_1328588024.1465775523274 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, June 12, 2016 at 9:32:22 PM UTC+2, Arth= ur O'Dwyer wrote:
On Sun, Jun 12, 2016 at 10:22 AM, <inkwizyt...@= gmail.com> wrote:
On Sunday, June 12, 2016 at 5:39:41 PM UTC+= 2, Tony V E wrote:
<= /div>
=C2=A0How do I break from the for constexpr, if '= break' doesn't do it?


`break` work same as in n= ormal `for`, critical is last `break` in original `switch` because `for con= stexpr` breaks there. I skip one transformation stage that show it:
swit= ch (x)
= {
=C2=A0 =C2=A0 case<= span style=3D"color:rgb(0,0,0)"> Op0::OpId: Op0::OpFunc();= goto finalFor;
= =C2=A0 =C2=A0 case Op1::OpId: Op1= ::OpFunc();= goto finalFor;
=C2=A0 = =C2=A0 case Op2::OpId: Op2::OpFunc(); goto= finalFor;
=C2=A0 =C2= =A0 case Op3::OpId: Op3::OpFunc(); goto finalFor;
=C2=A0 =C2=A0 fin= alFor: break;}

No, that doesn't work.=C2=A0= I think Tony has a point.
Sergey's half-proposal wants to ma= ke "break" and "continue" inside a "for constexpr&= quot; act exactly like "break" and "continue" inside a = non-constexpr "for":

=C2=A0 =C2=A0 for constexpr(typename T : Ts...) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do= _something<T>();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if constexpr(is_same_v<T, nullptr_t>) br= eak;
=C2=A0 =C2=A0 }

This code would generate an unrolled loop of= do_something<T>()s for ea= ch=C2=A0T in Ts... up to and including the first instance of nullptr_t. As soon as it generated = do_something<nullptr_t>(),= it would break and stop iterating over Ts....

You can't have break work this = way (Sergey's way) and also have it work for outer switch statements; y= ou have to pick one. And I think you've picked the wrong one, for two r= easons:

First, Ed Catmur has shown that if what yo= u really want is a way to pack-expand switch cases, there might be more nat= ural syntaxes to express that.

=C2=A0 =C2=A0 // Natively (this syntax strikes me as ungraceful= , I admit)
=C2=A0=C2=A0 =C2=A0switch (x)=C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 case Op::OpId: { Op::OpFunc(); break; }...
=C2=A0 =C2=A0 }


I start from that syntax and afte= r that I switch to `for constexpr` because it was for me lot more readable = and have more usages.
=C2=A0
=C2=A0 =C2=A0 // Or via some sort of library template
=C2=A0 =C2=A0 auto switch_ =3D make_switch(
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 make_switch_case( Op::OpId, [](){ return Op::OpFunc(); } )...
= =C2=A0 =C2=A0 );
=C2=A0 =C2=A0 auto result =3D switch_.on(x) + switch_.on(y= );

=C2=A0 =C2=A0 template<class X, class... Cs>
=C2=A0 =C2=A0 au= to switch_on(X&& x, Cs&&... cases) {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 return make_switch(std::forward<Cs>(cases)...).on(std::fo= rward<X>(x));
=C2=A0 =C2=A0 }


But it would be hard to generate code from = it that will be comparable with native `switch`.
=C2=A0
Second, I think you're doing the same thing I d= id at first, which is to treat "for constexpr" (or whatever) as a= pack-expansion primitive in the same vein as fold-expressions, whereas wha= t it really wants to be is a compile-time control-flow (code-generation) pr= imitive in the same vein as "if constexpr" and function templates= .. If you stop thinking of it as physically duplicating/unrolling its conten= ts (the way a fold-expression does), then you no longer have to worry about= what unrolling a "break" or "continue" statement would= mean.

I found the docs for Bo= ost.Switch. If I get the time, I'll try to write up a modern librar= y implementation of the above make_swit= ch=C2=A0and post it here. I'm sure it's been done before, of= course, so if someone beats me to it that's great.

=E2=80=93Arthur

=C2=A0On= e question how will work this code?
switch (0)
<= span style=3D"color: #660;" class=3D"styled-by-prettify">{
=C2=A0 =C2=A0 for (;;)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 f();
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 cas= e <= span style=3D"color: #066;" class=3D"styled-by-prettify">0: g(); break;
=C2=A0 =C2=A0 }=
=C2=A0 =C2=A0 h();
}
It will call `g` and then `h` because `break` is from `for= ` not from `switch`.
Now with `for constexpr`:
=
switch (0)
{
=C2=A0 =C2= =A0 for constexpr (int I : II...)=C2=A0 =C2=A0 {=C2=A0 =C2=A0 =C2=A0 =C2=A0 f<I>()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case I: g<I>(); break;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 h();
}
It will call `g<0>= ` and then `h`. Exactly same as for normal `for`. Only change is how `case`= is handled.

Overall I assume that `for constexpr` will conceptually= "unroll" body for each parameter pack element. This is need beca= use each "iteration" body can be completely different:
for constexpr (typename T : TT...)=
{
=C2=A0 =C2=A0 T x; //this will require creating sep= arate variable for each iteration, but they lifetime not overlap.
}
Proba= bly only real difference is when some iteration could create invalid code. = In my approach it will always be invalid, in case of "dynamic" co= ntrol-flow it can be valid if `for` leave early.
I think It could be pos= sible to tweak both approach to have same output based on reachability of e= ach iteration body. If is unreachable it will be not generated. Adding `cas= e` will made all iteration reachable and generated.


--
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.= com/a/isocpp.org/d/msgid/std-proposals/6b2c3588-e67e-4a8b-94d6-bdacd50ac244= %40isocpp.org.
------=_Part_494_1328588024.1465775523274-- ------=_Part_493_10668978.1465775523272-- .