220 26618 <9d82f1b6-b8cb-4b23-98de-329a0889d6b6@isocpp.org> article Path: news.gmane.org!not-for-mail From: "smilingthax via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Pack expansion: blocks, switch/case Date: Thu, 7 Jul 2016 09:34:46 -0700 (PDT) Lines: 263 Approved: news@gmane.org Message-ID: <9d82f1b6-b8cb-4b23-98de-329a0889d6b6@isocpp.org> References: <14ddd53c-8ec8-4e73-8f41-ebd8e33c2073@isocpp.org> <648eb3c5-488c-4b1b-8be2-02a0ac454220@isocpp.org> <8b6d75ab-6e5e-44ca-9ec6-c3c853ddbc38@isocpp.org> <2c5dbd16-d2c0-4a29-a64b-70b6425f3c55@isocpp.org> <24080b48-d084-4c5f-bb3f-fef677baee12@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4468_1502830075.1467909286980" X-Trace: ger.gmane.org 1467909292 17427 80.91.229.3 (7 Jul 2016 16:34:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 16:34:52 +0000 (UTC) Cc: smilingthax@googlemail.com, inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDC63VE4YQPBBKEJ7K5QKGQEO6RTKVI@isocpp.org Thu Jul 07 18:34:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bLCGI-0006OG-An for gclcip-std-proposals@m.gmane.org; Thu, 07 Jul 2016 18:34:50 +0200 Original-Received: by mail-pf0-f200.google.com with SMTP id 143sf45072213pfx.0 for ; Thu, 07 Jul 2016 09:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=7MusdJZQ1BOpOacycJ3zmDSNxX/qHjwCQDYfuHFF/jc=; b=k2TuLtlI6ytg06Tg/JhSQ/PjeEIPDm623KZ6LHZySFDy7ujJvXdcm0GjrZeuQfJQts /ck3k78K3NIjGYzZaYCJHJpu2XzRqtASD4cj6AAcuHInN71PtiewCcbiJP3QXU1hkphm M51QHXVeLJ1Pdq0XO9YPEXRmlMjgvFV44HBQUQjwgsuOoj5VNk52UOQB5gBQLW5HJKP/ 9VTsn+pk4RgxsAA1Ri1i8l9a5Ced/2ryu6IYC/MjC3kgI3xky3ViihS4YX31uPVxFT49 0HJJ22WsbG5A3v0WI4hP9HVhEaDJu8GYo6ybkSiN/sKecAXWMo0HBzpAqdnaSSOdLcUp gqZA== 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:cc: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=7MusdJZQ1BOpOacycJ3zmDSNxX/qHjwCQDYfuHFF/jc=; b=DXlmbqQMO5ARGJa/JdcH+bnI6NzmQXn11dvd4X3JBc5jXJ7nufDBnISuNv9rBMuCHr cZ9Uri1NpMtTBUv1lyt+bte5iDTYn8u3wgNScUn4WTBC1xZKlC1q00ExlZl6vHzzayLE EACBwJXIg+fh2aKJFUbvZkEU8YYFJvZ4dYzjPtkkEGHqK1pyLjvJHPp0o9yqzYjNjT9J J+yrb+K8RaeC5tqbPzQQtO2ArE2ULUDGCdVa/8t8ZddH+fGPytbP+Me9IqvQpQwHijqV 06+uIvmKJaF4vCj9/qnRYB1y2ysWYljnwulZUIL1XAWzmyIy9kIJ0je1ts3xSk9UxNJj ExFw== X-Gm-Message-State: ALyK8tLnjvJFxZv+9hLY6WG0GpF51JKXfkscJ+V7qQkHvNbKd67GW+hIWdwb90OOx4r/HQ== X-Received: by 10.98.22.204 with SMTP id 195mr969409pfw.0.1467909289113; Thu, 07 Jul 2016 09:34:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.129.6 with SMTP id q6ls366607itd.44.gmail; Thu, 07 Jul 2016 09:34:48 -0700 (PDT) X-Received: by 10.36.29.72 with SMTP id 69mr287306itj.0.1467909288062; Thu, 07 Jul 2016 09:34:48 -0700 (PDT) In-Reply-To: <24080b48-d084-4c5f-bb3f-fef677baee12@isocpp.org> X-Original-Sender: smilingthax@googlemail.com X-Original-From: smilingthax@googlemail.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:26618 Archived-At: ------=_Part_4468_1502830075.1467909286980 Content-Type: multipart/alternative; boundary="----=_Part_4469_1574063416.1467909286980" ------=_Part_4469_1574063416.1467909286980 Content-Type: text/plain; charset=UTF-8 On Thursday, July 7, 2016 at 4:29:05 PM UTC+2, inkwizyt...@gmail.com wrote: > > On Thursday, July 7, 2016 at 3:08:34 PM UTC+2, smili...@googlemail.com > wrote: >> >> Yes, `for constexpr` is far more verbose but this give us lot more >> control over that happens. Dots work great when you want expand one >> parameter pack but if is more of them or you want start do some complex >> thing this will start be problematic. >> > Image you want use Cartesian product of two parameters pack. Without > introducing completely new syntax you can't handle it. > You can implement product,pack>::type as a library solution just like zip<..>. The only difference is that, for Us=pair... you might want to add "using A = Us::first...;" and "using B = Us::second...;" for your convenience. > Of corse `for` have limitation too, but is lot of easier remove it. > Only thing that `for constexpr` need to handle nearly all possible use > cases is allow it to extract template parameters from concrete templates > (it would need have parameters like `template` or > `template`): > // we have two packs, T1 and T2 > template pack{}; > > for constexpr (typename A : pack) { } //pack merge > for constexpr (typename A : typename zip, pack>::type) > { } //zip two parameters pack, `type` is `pack...>` > for constexpr (typename A : pack) { for constexpr (typename B : > pack) { } } //cross of two packs, this could be same pack too > for constexpr (typename A : pack) { } //usage without > any parameter pack and outside any template > > And for `break` and `continue`. Only real problem there is `continue` > because `break` can be easy fix by adding one after `for`. Another is this > interaction should be well know for every one because is already same for > normal loops: [...] > The for constexpr proposal meshes two things together that don't have to: One half is the semantic of "for", esp. wrt. to the creation of a break/continue-scope. The other half is the "inline"-introduction of a new parameter pack (i.e. without another indirection like function call / template class). The first half is IMO only weakly motivated; when you think of it, even the name "for constexpr" is not exactly fitting, because you're (most importantly) dealing with *types*, not constexpr *values.* The second half can be dealt with without touching break/continue - or even forcing an expansion. Think about: using... Us = pack; // ... { doSomething }... // ... That's just a simple example, but the same thing works the same with product, zip, and all the stuff from above (you can add "using A = Ts::first;" as you like). The real questions are: How will "using..." (or "for constexpr") know how to "iterate the pack", i.e. find the variadic part? When we look at how range-for was specified, we can see that it does not "bless" a certain "range"-type, but uses whatever iterator begin() / end() would return. So we're now talking about "meta"-iterators over types, like Boost MPL - or Fusion - or Hana - or ... has. It's not like the *one true *solution in this space has already been around long enough just waiting to get standardized. Anyway, I don't think these considerations should hold us back from adding a *simple *statment/block-expansion facility to the language that already solves 95% of the most common use-cases. Tobias -- 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/9d82f1b6-b8cb-4b23-98de-329a0889d6b6%40isocpp.org. ------=_Part_4469_1574063416.1467909286980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, July 7, 2016 at 4:29:05 PM UTC+2, inkwizyt...= @gmail.com wrote:
On Thursday, July 7, 2016 at 3:08:34 PM UTC+2, smili...@googlemail.c= om wrote:
Yes, = `for constexpr` is far more verbose but this give us lot more control over = that happens. Dots work great when you want expand one parameter pack but i= f is more of them or you want start do some complex thing this will start b= e problematic.
Image you want use Cartesian prod= uct of two parameters pack. Without introducing completely new syntax you c= an't handle it.

You can imp= lement product<pack<T1...>,pack<T2...>>::type as a librar= y solution just like zip<..>. The only difference is that, for Us=3Dp= air<T1,T2>... you might want to add "using A =3D Us::first...;&q= uot; and "using B =3D Us::second...;" for your convenience.
=
=C2=A0
Of corse `for` have limitation too, but is lot of easier remove i= t.
Only thing that `for constexpr` need to handle nearly all possible us= e cases is allow it to extract template parameters from concrete templates = (it would need have parameters like `template<typename... T>` or `tem= plate<auto... A>`):
// we have two packs, = T1 and T2
template<typename...> pack{};

for constexpr= (typename A <= span style=3D"color:#660">: pack<T1..., T2...>) <= span style=3D"color:#660">{ } //pack merge
for constexpr (typename= A : typename<= span style=3D"color:#000"> zip<= pack<T1...>, pack<<= /span>T2...>= ;>::type) {= } //zip two p= arameters pack, `type` is `pack<std::pair<T1, T2>...>`
for constexpr (typename A = : pack<= span style=3D"color:#660"><T1...>) = { for constexpr (typename B : pack<T2...>)<= span style=3D"color:#000"> { } } //cross of two packs, this co= uld be same pack too
for constexpr (typename A : pack<int, long, char>) { } //usage without any parameter pack an= d outside any template

And for `break` and `continue`. Only real problem there is `= continue` because `break` can be easy fix by adding one after `for`. Anothe= r is this interaction should be well know for every one because is already = same for normal loops: [...]
=C2=A0
= The for constexpr proposal meshes two things together that don't have t= o: One half is the semantic of "for", esp. wrt. to the creation o= f a break/continue-scope. The other half is the "inline"-introduc= tion of a new parameter pack (i.e. without another indirection like functio= n call / template class).=C2=A0

The first half is IMO only we= akly motivated; when you think of it, even the name "for constexpr&quo= t; is not exactly fitting, because you're (most importantly) dealing wi= th types, not constexpr values.

The second half can be= dealt with without touching break/continue - or even forcing an expansion.= Think about:

=C2=A0 using... Us =3D pack<int= ,char,long>;
=C2=A0 // ...
=C2=A0 { doSomething<Us> }...
=C2=A0 // ...=
=

That's just a simple example, but the = same thing works the same with product, zip, and all the stuff from above (= you can add "using A =3D Ts::first;" as you like).

The rea= l questions are: How will "using..." (or "for constexpr"= ;) know how to "iterate the pack", i.e. find the variadic part?= =C2=A0
When we look at how range-for was specified, we can see that it d= oes not "bless" a certain "range"-type, but uses whatev= er iterator begin() / end() would return. So we're now talking about &q= uot;meta"-iterators over types, like Boost MPL - or Fusion - or Hana -= or ... has. It's not like the one true solution in this space h= as already been around long enough just waiting to get standardized.
Anyway, I don't think these considerations should hold us back from ad= ding a simple statment/block-expansion facility to the language that= already solves 95% of the most common use-cases.

= =C2=A0 Tobias

=C2=A0

--
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/9d82f1b6-b8cb-4b23-98de-329a0889d6b6= %40isocpp.org.
------=_Part_4469_1574063416.1467909286980-- ------=_Part_4468_1502830075.1467909286980-- .