Topic: Expansion of non-static data members


Author: Columbo <R.HL@gmx.net>
Date: Tue, 9 Oct 2018 08:00:21 -0700 (PDT)
Raw View
------=_Part_2137_1823109199.1539097221734
Content-Type: multipart/alternative;
 boundary="----=_Part_2138_915762178.1539097221734"

------=_Part_2138_915762178.1539097221734
Content-Type: text/plain; charset="UTF-8"

I realise this overlaps with the existing discussions on first-class tuples
in the language, but is there any current propositions on

template <typename... T> struct X {T... t;};

It would be nice to have this in some minimalistic manner until we have a
clear idea of what other surrounding features are meant to look like. I
remember seeing papers discussing syntax for dependent pack members, e.g.
Richard proposed .... IIRC (operator ...). Has someone tracked the progress
of these papers?

--
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/ab784542-1f2c-4e8b-afb0-a2278c3a08b5%40isocpp.org.

------=_Part_2138_915762178.1539097221734
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I realise this overlaps with the existing discussions on f=
irst-class tuples in the language, but is there any current propositions on=
<div><br></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt=
;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> X </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;};</span=
></div></code></div></div><br><div>It would be nice to have this in some mi=
nimalistic manner until we have a clear idea of what other surrounding feat=
ures are meant to look like. I remember seeing papers discussing syntax for=
 dependent pack members, e.g. Richard proposed <font face=3D"courier new, m=
onospace">....</font> IIRC (<font face=3D"courier new, monospace">operator =
....</font>). Has someone tracked the progress of these papers?=C2=A0</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab784542-1f2c-4e8b-afb0-a2278c3a08b5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab784542-1f2c-4e8b-afb0-a2278c3a08b5=
%40isocpp.org</a>.<br />

------=_Part_2138_915762178.1539097221734--

------=_Part_2137_1823109199.1539097221734--

.


Author: mihailnajdenov@gmail.com
Date: Tue, 9 Oct 2018 10:32:35 -0700 (PDT)
Raw View
------=_Part_2301_1828907832.1539106355364
Content-Type: multipart/alternative;
 boundary="----=_Part_2302_1857137929.1539106355364"

------=_Part_2302_1857137929.1539106355364
Content-Type: text/plain; charset="UTF-8"

Here,  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1061r0.html

I don't know of any other active papers.

On Tuesday, October 9, 2018 at 6:00:21 PM UTC+3, Columbo wrote:
>
> I realise this overlaps with the existing discussions on first-class
> tuples in the language, but is there any current propositions on
>
> template <typename... T> struct X {T... t;};
>
> It would be nice to have this in some minimalistic manner until we have a
> clear idea of what other surrounding features are meant to look like. I
> remember seeing papers discussing syntax for dependent pack members, e.g.
> Richard proposed .... IIRC (operator ...). Has someone tracked the
> progress of these papers?
>

--
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/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%40isocpp.org.

------=_Part_2302_1857137929.1539106355364
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Here,=C2=A0 http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2018/p1061r0.html</div><div><br></div><div>I=C2=A0<span style=3D"=
display: inline !important; float: none; background-color: transparent; col=
or: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,s=
ans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-=
weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-dec=
oration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-=
width: 0px; white-space: normal; word-spacing: 0px;">don&#39;t know of any =
other active papers.</span></div><b></b><i></i><u></u><sub></sub><sup></sup=
><strike></strike><br>On Tuesday, October 9, 2018 at 6:00:21 PM UTC+3, Colu=
mbo wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I r=
ealise this overlaps with the existing discussions on first-class tuples in=
 the language, but is there any current propositions on<div><br></div><div>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#008">template</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</s=
pan><span style=3D"color:#660">...</span><span style=3D"color:#000"> T</spa=
n><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">struct</span><span style=3D"color:#000"> X </spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000">T</span><sp=
an style=3D"color:#660">...</span><span style=3D"color:#000"> t</span><span=
 style=3D"color:#660">;};</span></div></code></div></div><br><div>It would =
be nice to have this in some minimalistic manner until we have a clear idea=
 of what other surrounding features are meant to look like. I remember seei=
ng papers discussing syntax for dependent pack members, e.g. Richard propos=
ed <font face=3D"courier new, monospace">....</font> IIRC (<font face=3D"co=
urier new, monospace">operator ...</font>). Has someone tracked the progres=
s of these papers?=C2=A0</div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88=
%40isocpp.org</a>.<br />

------=_Part_2302_1857137929.1539106355364--

------=_Part_2301_1828907832.1539106355364--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 11 Oct 2018 13:20:32 -0700
Raw View
--00000000000091987f0577f9b423
Content-Type: text/plain; charset="UTF-8"

One problem with a proposal such as this is that when parsing something
like:

template<typename T> void f(X x) { g(x.y.a + h(x).z.b ...); }

.... the compiler has no idea where the packs are within the pack expansion.
That's pretty much fatal to more or less all current implementation
strategies for variadic templates.

If we had explicit syntax to identify where the packs are: (note: strawman
syntax)

template<typename T> void f(X x) { g(x.y. ...a + h(x). ...z.b ...); }

.... then the compiler could work out that it has to first substitute into
'x.y' to determine the arity of 'a', and into 'h(x)' to determine the arity
of 'h(x).z'.

Another potential stumbling block for most proposals in this area is that
they introduce the possibility of encountering packs outside templates;
when processing code that involves potentially-variadic pack expansion,
some compilers enter a fundamentally different parsing mode (their usual
mode essentially generates code from expressions as they go, but for a pack
expansion you need to do something quite different because you don't know
how many times you'll need to repeat any given construct -- and that number
might even be zero!); if pack expansions can appear out of the blue,
anywhere, then this mode must be used all the time, which might have a
significant deleterious effect on compilation times. (However, the one
compiler that I know of that does something like this has undergone a
fairly substantial rewrite, so I don't know whether this is still a problem
for any current C++ compilers.)

The challenge would be to find a way to make this work without the result
being ugly, and without ruling out current common implementation strategies.

On Tue, 9 Oct 2018 at 10:32, <mihailnajdenov@gmail.com> wrote:

> Here,
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1061r0.html
>
> I don't know of any other active papers.
>
> On Tuesday, October 9, 2018 at 6:00:21 PM UTC+3, Columbo wrote:
>>
>> I realise this overlaps with the existing discussions on first-class
>> tuples in the language, but is there any current propositions on
>>
>> template <typename... T> struct X {T... t;};
>>
>> It would be nice to have this in some minimalistic manner until we have a
>> clear idea of what other surrounding features are meant to look like. I
>> remember seeing papers discussing syntax for dependent pack members, e.g.
>> Richard proposed .... IIRC (operator ...). Has someone tracked the
>> progress of these papers?
>>
> --
> 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/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQqnQuGfT5dCbDbjOmKqUfx14R7w5LErkJHtN9zqi9kB0GA%40mail.gmail.com.

--00000000000091987f0577f9b423
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One problem with a proposal such as this is that when pars=
ing something like:<div><br></div><div>template&lt;typename T&gt; void f(X =
x) { g(x.y.a + h(x).z.b ...); }</div><div><br></div><div>... the compiler h=
as no idea where the packs are within the pack expansion. That&#39;s pretty=
 much fatal to more or less all current implementation strategies for varia=
dic templates.</div><div><br></div><div>If we had explicit syntax to identi=
fy where the packs are: (note: strawman syntax)</div><div><br></div><div>te=
mplate&lt;typename T&gt; void f(X x) { g(x.y. ...a + h(x). ...z.b ...); }</=
div><div><br></div><div>... then the compiler could work out that it has to=
 first substitute into &#39;x.y&#39; to determine the arity of &#39;a&#39;,=
 and into &#39;h(x)&#39; to determine the arity of &#39;h(x).z&#39;.</div><=
div><br></div><div>Another potential stumbling block for most proposals in =
this area is that they introduce the possibility of encountering packs outs=
ide templates; when processing code that involves potentially-variadic pack=
 expansion, some compilers enter a fundamentally different parsing mode (th=
eir usual mode essentially generates code from expressions as they go, but =
for a pack expansion you need to do something quite different because you d=
on&#39;t know how many times you&#39;ll need to repeat any given construct =
-- and that number might even be zero!); if pack expansions can appear out =
of the blue, anywhere, then this mode must be used all the time, which migh=
t have a significant deleterious effect on compilation times. (However, the=
 one compiler that I know of that does something like this has undergone a =
fairly substantial rewrite, so I don&#39;t know whether this is still a pro=
blem for any current C++ compilers.)</div><div><br></div><div>The challenge=
 would be to find a way to make this work without the result being ugly, an=
d without ruling out current common implementation strategies.</div><div><d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 9 Oct 2018 at 10=
:32, &lt;<a href=3D"mailto:mihailnajdenov@gmail.com">mihailnajdenov@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Here,=C2=A0 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2018/p1061r0.html" target=3D"_blank">http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2018/p1061r0.html</a></div><div><br></div><div>I=C2=A0<spa=
n style=3D"display:inline!important;float:none;background-color:transparent=
;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sa=
ns-serif;font-size:13px;font-style:normal;font-variant:normal;font-weight:4=
00;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0=
px;text-transform:none;white-space:normal;word-spacing:0px">don&#39;t know =
of any other active papers.</span></div><b></b><i></i><u></u><sub></sub><su=
p></sup><strike></strike><br>On Tuesday, October 9, 2018 at 6:00:21 PM UTC+=
3, Columbo wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I=
 realise this overlaps with the existing discussions on first-class tuples =
in the language, but is there any current propositions on<div><br></div><di=
v><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
span style=3D"color:#008">template</span><span style=3D"color:#000"> </span=
><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename<=
/span><span style=3D"color:#660">...</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">struct</span><span style=3D"color:#000"> X </s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000">T</span><=
span style=3D"color:#660">...</span><span style=3D"color:#000"> t</span><sp=
an style=3D"color:#660">;};</span></div></code></div></div><br><div>It woul=
d be nice to have this in some minimalistic manner until we have a clear id=
ea of what other surrounding features are meant to look like. I remember se=
eing papers discussing syntax for dependent pack members, e.g. Richard prop=
osed <font face=3D"courier new, monospace">....</font> IIRC (<font face=3D"=
courier new, monospace">operator ...</font>). Has someone tracked the progr=
ess of these papers?=C2=A0</div></div></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-451f-83d4-fe1d1ec8ab88%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d4bcbea-cae9-=
451f-83d4-fe1d1ec8ab88%40isocpp.org</a>.<br>
</blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnQuGfT5dCbDbjOmKqUfx14R7w5LErk=
JHtN9zqi9kB0GA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnQuGfT5dCb=
DbjOmKqUfx14R7w5LErkJHtN9zqi9kB0GA%40mail.gmail.com</a>.<br />

--00000000000091987f0577f9b423--

.