Topic: Fixed Size Parameter Packs - Proposal
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Mon, 26 May 2014 10:48:59 +0200
Raw View
Hi!
Here's the draft for my proposal: http://random.m-ou.se/fspp.html
Feedback is greatly appreciated.
Thanks!
-Maurice-
--
---
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/.
.
Author: Stack Machine <stackmachine@hotmail.com>
Date: Mon, 26 May 2014 02:09:03 -0700 (PDT)
Raw View
------=_Part_46_10723222.1401095344160
Content-Type: text/plain; charset=UTF-8
Why aren't empty parameter packs allowed?
--
---
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_46_10723222.1401095344160
Content-Type: text/html; charset=UTF-8
Why aren't empty parameter packs allowed?<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_46_10723222.1401095344160--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 26 May 2014 12:09:51 +0300
Raw View
On 26 May 2014 11:48, Maurice Bos <m-ou.se@m-ou.se> wrote:
> Hi!
>
> Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>
> Feedback is greatly appreciated.
I certainly think the proposal has enough merit that it should be discussed
in the Evolution Working Group.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 26 May 2014 17:12:08 +0800
Raw View
--Apple-Mail=_685D8207-FF3E-42FD-9D27-C60B9D944DCE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
I haven't read in detail yet, but I agree with the identified problem.
The name might be confusing. I would recommend calling it something more li=
ke non-dependent pack patterns, or pack-like repetition (PLR has a ring to =
it).
my_vector(int...[N] v) : values{v...} {}
Here int appears to be used as a pack pattern, expanded with ...[N]. But in=
t doesn't name a pack.
In other examples, you show N being deduced, so it isn't fixed.
As for technical specification, what we might need is the construct pattern=
...[ constant-expression ] such that the pattern does not contain an unexp=
anded pack, and the constant-expression is a deduced context if it names a =
template parameter. The list of applicable patterns should be a subset of =
=A714.5.3/4, perhaps only function and template parameter declarations.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_685D8207-FF3E-42FD-9D27-C60B9D944DCE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">I haven’t read i=
n detail yet, but I agree with the identified problem.<div><br></div><div>T=
he name might be confusing. I would recommend calling it something more lik=
e non-dependent pack patterns, or pack-like repetition (PLR has a ring to i=
t).</div><div><br></div><div><font face=3D"Courier"> my_vector=
(int...[N] v) : values{v...} {}</font></div><div><br></div><div>Here <font =
face=3D"Courier">int</font> appears to be used as a pack pattern, expanded =
with <font face=3D"Courier">...</font><font face=3D"Courier">[N]</font>. Bu=
t int doesn’t name a pack.</div><div><br></div><div>In other examples=
, you show N being deduced, so it isn’t fixed.</div><div><br></div><d=
iv>As for technical specification, what we might need is the construct <fon=
t face=3D"Courier">pattern ...[ constant-expression ]</font> such=
that the pattern does <i>not</i> contain an unexpanded pack, and the =
<i>constant-expression</i> is a deduced context if it names a template para=
meter. The list of applicable patterns should be a subset of =A714.5.3/4, p=
erhaps only function and template parameter declarations.</div><div><br></d=
iv></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_685D8207-FF3E-42FD-9D27-C60B9D944DCE--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Mon, 26 May 2014 12:36:13 +0300
Raw View
------MAE6N2SRQRP097AA90TOGKHZ4L9OXP
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
This has significant consequences in enhancing the readability of complex s=
finae-heavy template metaprogramming by making pattern matching through tag=
dispatching easier when it comes to function templates. It would also allo=
w for class template partial specializations to factor out sfinae uses in t=
he type parameters used in a given partial specialization through the evalu=
ation of N.
Is there a reason why you would not be able to use template template parame=
ters as well directly (without wrapping them with a class template) with th=
is syntax? I do not see them mentioned or in the examples of your current d=
raft. They too make an important computational construct in template metapr=
ogramming.
Overall, I think that metaprogrammers would be delighted by your proposal. =
Also, it does not require any previous code to be altered if introduced int=
o the standard. Simple and dazzling.
On May 26, 2014 11:48:59 AM EEST, Maurice Bos <m-ou.se@m-ou.se> wrote:
>Hi!
>
>Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>
>Feedback is greatly appreciated.
>
>Thanks!
>
>-Maurice-
>
>--=20
>
>---=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 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/.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------MAE6N2SRQRP097AA90TOGKHZ4L9OXP
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">This has significant consequences i=
n enhancing the readability of complex sfinae-heavy template metaprogrammin=
g by making pattern matching through tag dispatching easier when it comes t=
o function templates. It would also allow for class template partial specia=
lizations to factor out sfinae uses in the type parameters used in a given =
partial specialization through the evaluation of N.</p>
<p dir=3D"ltr">Is there a reason why you would not be able to use template =
template parameters as well directly (without wrapping them with a class te=
mplate) with this syntax? I do not see them mentioned or in the examples of=
your current draft. They too make an important computational construct in =
template metaprogramming.</p>
<p dir=3D"ltr">Overall, I think that metaprogrammers would be delighted by =
your proposal. Also, it does not require any previous code to be altered if=
introduced into the standard. Simple and dazzling.</p>
<br><br><div class=3D"gmail_quote">On May 26, 2014 11:48:59 AM EEST, Mauric=
e Bos <<a href=3D"http://m-ou.se">m-ou.se</a>@m-ou.se> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">Hi!<br /><br />Here's the draft for my proposal: <a h=
ref=3D"http://random.m-ou.se/fspp.html">http://random.m-ou.se/fspp.html</a>=
<br /><br />Feedback is greatly appreciated.<br /><br />Thanks!<br /><br />=
-Maurice-<br /></pre></blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------MAE6N2SRQRP097AA90TOGKHZ4L9OXP--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 26 May 2014 12:34:14 +0200
Raw View
--001a11c32c56e6d10004fa4b1ed3
Content-Type: text/plain; charset=UTF-8
Maurice,
What about, in addition to:
template<size_t N> void f(int...[N]);
you propose:
void f(int...[]);
The size of the pack can be determined with sizeof... as usual. The
trailing empty square brackets disambiguate from the C-style variable
arguments ellipsis. The presence of the pack parameter in the declarator
implcitly turns the declaration into a template declaration. You might
want to take a look at the latest Concept spec for ideas about this kind of
implicit template declaration machinery.
Also, normally sequences of homogeneous type are represented with arrays
and array-like containers (like std::array). You should consider carefully
the relationship between arrays and your proposal. I see in your first
three use cases you are comparing against std::tuple<int, int, int> and not
int[3] nor std::array<int,3>.
That is, I think you should discuss the relationship between f(int, int,
int), f(int[3]) and f(std::array<int,3>)
Regards,
Andrew.
On Mon, May 26, 2014 at 10:48 AM, Maurice Bos <m-ou.se@m-ou.se> wrote:
> Hi!
>
> Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>
> Feedback is greatly appreciated.
>
> Thanks!
>
> -Maurice-
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c32c56e6d10004fa4b1ed3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Maurice,<div><br></div><div>What about, in addition to:</d=
iv><div><br></div><div>=C2=A0 =C2=A0 template<size_t N> void f(int...=
[N]);</div><div><br></div><div>you propose:</div><div><br></div><div>=C2=A0=
=C2=A0 void f(int...[]);</div>
<div><br></div><div>The size of the pack can be determined with sizeof... a=
s usual. =C2=A0The trailing empty square brackets disambiguate from the C-s=
tyle variable arguments ellipsis. =C2=A0The presence of the pack parameter =
in the declarator implcitly turns the declaration into a template declarati=
on. =C2=A0You might want to take a look at the latest Concept spec for idea=
s about this kind of implicit template declaration machinery.</div>
<div><br></div><div>Also, normally sequences of homogeneous type are repres=
ented with arrays and array-like containers (like std::array). =C2=A0You sh=
ould consider carefully the relationship between arrays and your proposal. =
=C2=A0I see in your first three use cases you are comparing against std::tu=
ple<int, int, int> and not int[3] nor std::array<int,3>.</div>
<div><br></div><div>That is, I think you should discuss the relationship be=
tween f(int, int, int), f(int[3]) and f(std::array<int,3>)</div><div>=
<br></div><div>Regards,</div><div>Andrew.</div><div><br></div><div><font co=
lor=3D"#000000"><br>
</font></div><div><font color=3D"#000000"><br></font></div><div><font color=
=3D"#000000"><br></font></div></div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">On Mon, May 26, 2014 at 10:48 AM, Maurice Bos <span =
dir=3D"ltr"><<a href=3D"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.s=
e@m-ou.se</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi!<br>
<br>
Here's the draft for my proposal: <a href=3D"http://random.m-ou.se/fspp=
..html" target=3D"_blank">http://random.m-ou.se/fspp.html</a><br>
<br>
Feedback is greatly appreciated.<br>
<br>
Thanks!<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Maurice-<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c32c56e6d10004fa4b1ed3--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 26 May 2014 18:35:37 +0800
Raw View
--Apple-Mail=_0975389C-559B-4634-B657-CAD6B322B919
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-26, at 5:12 PM, David Krauss <potswa@gmail.com> wrote:
> As for technical specification, what we might need is the construct patte=
rn ...[ constant-expression ] such that the pattern does not contain an une=
xpanded pack, and the constant-expression is a deduced context if it names =
a template parameter. The list of applicable patterns should be a subset of=
=A714.5.3/4, perhaps only function and template parameter declarations.
More specifically, the bracketed expression could be added to declarator-id=
but not to other instances of the ellipsis.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_0975389C-559B-4634-B657-CAD6B322B919
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webk=
it-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>=
On 2014–05–26, at 5:12 PM, David Krauss <<a href=3D"mailto:p=
otswa@gmail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-in=
terchange-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Ty=
pe" content=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: b=
reak-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;=
">As for technical specification, what we might need is the construct <font=
face=3D"Courier">pattern ...[ constant-expression ]</font> such =
that the pattern does <i>not</i> contain an unexpanded pack, and the <=
i>constant-expression</i> is a deduced context if it names a template param=
eter. The list of applicable patterns should be a subset of =A714.5.3/4, pe=
rhaps only function and template parameter declarations.</div></blockquote>=
</div><br><div>More specifically, the bracketed expression could be added t=
o <i>declarator-id</i> but not to other instances of the ellipsis.</div><di=
v><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_0975389C-559B-4634-B657-CAD6B322B919--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Mon, 26 May 2014 14:15:28 +0300
Raw View
This is a multi-part message in MIME format.
--------------070202080605010104070900
Content-Type: text/plain; charset=UTF-8; format=flowed
There is also another couple of issues to note here related to both
naming and other semantics asides my previous email.
Let's take naming first. David Krauss writes in another message on this
thread:
On 05/26/2014 12:12 PM, David Krauss wrote:
> The name might be confusing. I would recommend calling it something
> more like non-dependent pack patterns, or pack-like repetition (PLR
> has a ring to it).
What Maurice Bos proposes is actually *bounded expansion unpacking* over
*unbounded expansion* which is the current modus operandi of the
ellipsis-only unpack operator. I think that given we are talking about
expansion, the ellipsis unpack operator should identify unbounded pack
expansion while the ...[N] (ellipsis-subscript?) operator should
identify bounded pack expansion.
Though repetition can be obtained through expansion, the two are not the
same thing since said ...[] operator can homeomorphically deal with type
parameters, non type - parameters and template template parameters alike.
On to another thing now, let's think of the following syntax:
/*
* This is fictional syntax right now, for study purposes
* and N,K,M are constant expressions...
*/
*template*<*typename*...[N] A1,*typename*...[K] A2,*typename*...[M] A3>
*struct* example0 {
/* How should combination of N,K,M into a nested function
* or class template be treated?*/
};
*template*<*template*<*typename*...>*class*...[N] T1>
*struct* example1 {
/* same as example0*/
};
*template*<*template*<*typename*...[K]>*class*...[N] T1>
*struct* example2 {
/* same as example0, additional one level of nesting*/
};
*template*<*template*<*template*<*typename*...[M]>*class*...[K]>*class*...[N] T1>
*struct* example3 {
/* same as example0, two levels of nesting with TTP*/
};
The unbounded unpack operator (ellipsis) has some interesting
combinatorial properties when unpacking where multiple parameter packs
are used in combination. Which should be the syntax for such occasions?
On to a third point but important point, should there be a rule when
matching occurs between bounded and unbounded pack expansion using the
ellipsis-subscript operator when the following two signatures are met?
/*
* This is fictional syntax right now, for the Bos draft proposal.
*/
struct metamonger {
*template*<*typename*...[N] Args>
void function(Args...) {/* bounded pack expansion, would be better with Args...[N]*/
}
*template*<*typename*... Args>
void function(Args...) {/* unbounded pack expansion*/
}
/*
* The problem is obvious, for when sizeof...(Args) = N this should
* be considered ambiguous, if only it were that simple...
*/
I do not think that this is a simple case because it would force the
programmer to again use sfinae or tag dispatching to make sure that
there is no conflict when such an occasion is met. There has to be some
sort of priority here when used with function templates or this is going
to require the programmer to resort to amending the code for when
sizeof..(Args) = N. Not using ellipsis-subscript to differentiate from
the ellipsis only parameter unpacking (aka unbounded pack expansion) is
problematic as well for defining such priority.
Then there is another thing about whether or not we should be accepting
multidimensional ellipsis subscript operators in this case, for mixing
bounded and unbounded parameter pack expansion:
/* in this example, N and K are decided*/
*template*<std::size_t N, std::size_t K,*typename*...[N][K] Args>
void function(Args...[N][K]) {
/* this is where it gets VERY interesting*/
}
/* in this example, N K are fixed*/
*template*<*typename*...[N][K] Args>
void function(Args...[N][K]) {
/* this is where it gets VERY interesting, especially if Args are not of the same type*/
}
This can also lead to the function type signature collision as well with
unbound parameter pack expansion. It also makes evident why during
unpacking, ellipsis-subscript should be reused instead of ellipsis alone.
Lots of other things to say, but for the time being I cut it here.
On 05/26/2014 12:36 PM, George Makrydakis wrote:
>
> This has significant consequences in enhancing the readability of
> complex sfinae-heavy template metaprogramming by making pattern
> matching through tag dispatching easier when it comes to function
> templates. It would also allow for class template partial
> specializations to factor out sfinae uses in the type parameters used
> in a given partial specialization through the evaluation of N.
>
> Is there a reason why you would not be able to use template template
> parameters as well directly (without wrapping them with a class
> template) with this syntax? I do not see them mentioned or in the
> examples of your current draft. They too make an important
> computational construct in template metaprogramming.
>
> Overall, I think that metaprogrammers would be delighted by your
> proposal. Also, it does not require any previous code to be altered if
> introduced into the standard. Simple and dazzling.
>
>
>
> On May 26, 2014 11:48:59 AM EEST, Maurice Bos <m-ou.se
> <http://m-ou.se>@m-ou.se> wrote:
>
> Hi!
>
> Here's the draft for my proposal:http://random.m-ou.se/fspp.html
>
> Feedback is greatly appreciated.
>
> Thanks!
>
> -Maurice-
>
--
---
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/.
--------------070202080605010104070900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
There is also another couple of=C2=A0 issues to note here related to bo=
th
naming and other semantics asides my previous email.<br>
<br>
Let's take naming first. David Krauss writes in another message on
this thread:<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 12:12 PM, David Krauss
wrote:</div>
<blockquote type=3D"cite">The name might be confusing. I would
recommend calling it something more like non-dependent pack
patterns, or pack-like repetition (PLR has a ring to it).</blockquote=
>
<br>
What Maurice Bos proposes is actually *bounded expansion unpacking*
over *unbounded expansion* which is the current modus operandi of
the ellipsis-only unpack operator. I think that given we are talking
about expansion, the ellipsis unpack operator should identify
unbounded pack expansion while the ...[N] (ellipsis-subscript?)
operator should identify bounded pack expansion. <br>
<br>
Though repetition can be obtained through expansion, the two are not
the same thing since said ...[] operator can homeomorphically deal
with type parameters, non type - parameters and template template
parameters alike.<br>
<br>
On to another thing now, let's think of the following syntax:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span>
<span style=3D"color:#898887;"> * This is fictional syntax right now, for s=
tudy purposes</span>
<span style=3D"color:#898887;"> * and N,K,M are constant expressions...</sp=
an>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b><<b>typename</b>...[N] A1, <b>typename</b>...[K] A2, <b>t=
ypename</b>...[M] A3>
<b>struct</b> example0 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
How should combination of N,K,M into a nested function</span>
<span style=3D"color:#898887;"> * or class template be treated? </span>=
<span style=3D"color:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>typename</b>...> <b>class</b>..=
..[N] T1>
<b>struct</b> example1 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0 </span><span style=3D"color:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>typename</b>...[K]> <b>class</b=
>...[N] T1>
<b>struct</b> example2 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0, additional one level of nesting </span><span style=3D"co=
lor:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>template</b><<b>typename</b>...=
[M]> <b>class</b>...[K]> <b>class</b>...[N] T1>
<b>struct</b> example3 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0, two levels of nesting with TTP </span><span style=3D"col=
or:#898887;">*/</span>
};
</pre>
The unbounded unpack operator (ellipsis) has some interesting
combinatorial properties when unpacking where multiple parameter
packs are used in combination. Which should be the syntax for such
occasions?<br>
<br>
On to a third point but important point, should there be a rule when
matching occurs between bounded and unbounded pack expansion using
the ellipsis-subscript operator when the following two signatures
are met?<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span>
<span style=3D"color:#898887;"> * This is fictional syntax right now, for t=
he Bos draft proposal.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
struct metamonger {
<b>template</b><<b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> bounded pack e=
xpansion, would be better with Args...[N] </span><span style=3D"color:#8988=
87;">*/</span>
}
<b>template</b><<b>typename</b>... Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> unbounded pack=
expansion </span><span style=3D"color:#898887;">*/</span>
}<span style=3D"color:#0057ae;"></span><span style=3D"color:#898887;"></spa=
n><span style=3D"color:#898887;"></span><span style=3D"color:#898887;"></sp=
an>
<span style=3D"color:#898887;">/*</span>
<span style=3D"color:#898887;"> * The problem is obvious, for when sizeof..=
..(Args) =3D N this should</span>
<span style=3D"color:#898887;"> * be considered ambiguous, if only it were =
that simple...</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
</pre>
I do not think that this is a simple case because it would force the
programmer to again use sfinae or tag dispatching to make sure that
there is no conflict when such an occasion is met. There has to be
some sort of priority here when used with function templates or this
is going to require the programmer to resort to amending the code
for when sizeof..(Args) =3D N. Not using ellipsis-subscript to
differentiate from the ellipsis only parameter unpacking (aka
unbounded pack expansion) is problematic as well for defining such
priority.<br>
<br>
Then there is another thing about whether or not we should be
accepting multidimensional ellipsis subscript operators in this
case, for mixing bounded and unbounded parameter pack expansion:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span><span style=3D"color:#898887;"> in this example, N =
and K are decided </span><span style=3D"color:#898887;">*/</span>
<b>template</b><std::size_t N, std::size_t K, <b>typename</b>...[N][K] A=
rgs>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting </span><span style=3D"color:#898887=
;">*/</span>
}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> in =
this example, N K are fixed </span><span style=3D"color:#898887;">*/</span>
<b>template</b><<b>typename</b>...[N][K] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting, especially if Args are not of the =
same type </span><span style=3D"color:#898887;">*/</span>
}</pre>
<br>
This can also lead to the function type signature collision as well
with unbound parameter pack expansion. It also makes evident why
during unpacking, ellipsis-subscript should be reused instead of
ellipsis alone.<br>
<br>
Lots of other things to say, but for the time being I cut it here.<br>
<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 12:36 PM, George
Makrydakis wrote:<br>
</div>
<blockquote
cite=3D"mid:8cdcc577-65a8-48a5-89f5-0b03c2bdc23c@email.android.com"
type=3D"cite">
<p dir=3D"ltr">This has significant consequences in enhancing the
readability of complex sfinae-heavy template metaprogramming by
making pattern matching through tag dispatching easier when it
comes to function templates. It would also allow for class
template partial specializations to factor out sfinae uses in
the type parameters used in a given partial specialization
through the evaluation of N.</p>
<p dir=3D"ltr">Is there a reason why you would not be able to use
template template parameters as well directly (without wrapping
them with a class template) with this syntax? I do not see them
mentioned or in the examples of your current draft. They too
make an important computational construct in template
metaprogramming.</p>
<p dir=3D"ltr">Overall, I think that metaprogrammers would be
delighted by your proposal. Also, it does not require any
previous code to be altered if introduced into the standard.
Simple and dazzling.</p>
<br>
<br>
<div class=3D"gmail_quote">On May 26, 2014 11:48:59 AM EEST, Maurice
Bos <<a moz-do-not-send=3D"true" href=3D"http://m-ou.se">m-ou.se=
</a>@m-ou.se>
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre class=3D"k9mail">Hi!
Here's the draft for my proposal: <a moz-do-not-send=3D"true" href=3D"http:=
//random.m-ou.se/fspp.html">http://random.m-ou.se/fspp.html</a>
Feedback is greatly appreciated.
Thanks!
-Maurice-
</pre>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070202080605010104070900--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Mon, 26 May 2014 14:21:39 +0300
Raw View
This is a multi-part message in MIME format.
--------------000807020200040905060406
Content-Type: text/plain; charset=UTF-8; format=flowed
A small editing fix in the semantics used:
Types...[N] = ellipsis-subscript unpacking, denoting *bounded parameter
pack expansion*
Types... = ellipsis unpacking, denoting *unbounded parameter pack
expansion*
Thanks
On 05/26/2014 02:15 PM, George Makrydakis wrote:
> There is also another couple of issues to note here related to both
> naming and other semantics asides my previous email.
>
> Let's take naming first. David Krauss writes in another message on
> this thread:
>
> On 05/26/2014 12:12 PM, David Krauss wrote:
>> The name might be confusing. I would recommend calling it something
>> more like non-dependent pack patterns, or pack-like repetition (PLR
>> has a ring to it).
>
> What Maurice Bos proposes is actually *bounded expansion unpacking*
> over *unbounded expansion* which is the current modus operandi of the
> ellipsis-only unpack operator. I think that given we are talking about
> expansion, the ellipsis unpack operator should identify unbounded pack
> expansion while the ...[N] (ellipsis-subscript?) operator should
> identify bounded pack expansion.
>
> Though repetition can be obtained through expansion, the two are not
> the same thing since said ...[] operator can homeomorphically deal
> with type parameters, non type - parameters and template template
> parameters alike.
>
> On to another thing now, let's think of the following syntax:
>
> /*
> * This is fictional syntax right now, for study purposes
> * and N,K,M are constant expressions...
> */
>
> *template*<*typename*...[N] A1,*typename*...[K] A2,*typename*...[M] A3>
> *struct* example0 {
> /* How should combination of N,K,M into a nested function
> * or class template be treated?*/
> };
>
> *template*<*template*<*typename*...>*class*...[N] T1>
> *struct* example1 {
> /* same as example0*/
> };
>
> *template*<*template*<*typename*...[K]>*class*...[N] T1>
> *struct* example2 {
> /* same as example0, additional one level of nesting*/
> };
>
> *template*<*template*<*template*<*typename*...[M]>*class*...[K]>*class*...[N] T1>
> *struct* example3 {
> /* same as example0, two levels of nesting with TTP*/
> };
>
> The unbounded unpack operator (ellipsis) has some interesting
> combinatorial properties when unpacking where multiple parameter packs
> are used in combination. Which should be the syntax for such occasions?
>
> On to a third point but important point, should there be a rule when
> matching occurs between bounded and unbounded pack expansion using the
> ellipsis-subscript operator when the following two signatures are met?
> /*
> * This is fictional syntax right now, for the Bos draft proposal.
> */
>
> struct metamonger {
> *template*<*typename*...[N] Args>
> void function(Args...) {/* bounded pack expansion, would be better with Args...[N]*/
> }
>
> *template*<*typename*... Args>
> void function(Args...) {/* unbounded pack expansion*/
> }
>
> /*
> * The problem is obvious, for when sizeof...(Args) = N this should
> * be considered ambiguous, if only it were that simple...
> */
> I do not think that this is a simple case because it would force the
> programmer to again use sfinae or tag dispatching to make sure that
> there is no conflict when such an occasion is met. There has to be
> some sort of priority here when used with function templates or this
> is going to require the programmer to resort to amending the code for
> when sizeof..(Args) = N. Not using ellipsis-subscript to differentiate
> from the ellipsis only parameter unpacking (aka unbounded pack
> expansion) is problematic as well for defining such priority.
>
> Then there is another thing about whether or not we should be
> accepting multidimensional ellipsis subscript operators in this case,
> for mixing bounded and unbounded parameter pack expansion:
>
> /* in this example, N and K are decided*/
> *template*<std::size_t N, std::size_t K,*typename*...[N][K] Args>
> void function(Args...[N][K]) {
> /* this is where it gets VERY interesting*/
> }
>
> /* in this example, N K are fixed*/
> *template*<*typename*...[N][K] Args>
> void function(Args...[N][K]) {
> /* this is where it gets VERY interesting, especially if Args are not of the same type*/
> }
>
> This can also lead to the function type signature collision as well
> with unbound parameter pack expansion. It also makes evident why
> during unpacking, ellipsis-subscript should be reused instead of
> ellipsis alone.
>
> Lots of other things to say, but for the time being I cut it here.
>
>
> On 05/26/2014 12:36 PM, George Makrydakis wrote:
>>
>> This has significant consequences in enhancing the readability of
>> complex sfinae-heavy template metaprogramming by making pattern
>> matching through tag dispatching easier when it comes to function
>> templates. It would also allow for class template partial
>> specializations to factor out sfinae uses in the type parameters used
>> in a given partial specialization through the evaluation of N.
>>
>> Is there a reason why you would not be able to use template template
>> parameters as well directly (without wrapping them with a class
>> template) with this syntax? I do not see them mentioned or in the
>> examples of your current draft. They too make an important
>> computational construct in template metaprogramming.
>>
>> Overall, I think that metaprogrammers would be delighted by your
>> proposal. Also, it does not require any previous code to be altered
>> if introduced into the standard. Simple and dazzling.
>>
>>
>>
>> On May 26, 2014 11:48:59 AM EEST, Maurice Bos <m-ou.se
>> <http://m-ou.se>@m-ou.se> wrote:
>>
>> Hi!
>>
>> Here's the draft for my proposal:http://random.m-ou.se/fspp.html
>>
>> Feedback is greatly appreciated.
>>
>> Thanks!
>>
>> -Maurice-
>>
>
--
---
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/.
--------------000807020200040905060406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
A small editing fix in the semantics used:<br>
<br>
Types...[N] =3D ellipsis-subscript unpacking, denoting <b>bounded
parameter pack expansion</b><br>
Types...=C2=A0=C2=A0 =3D ellipsis unpacking, denoting <b>unbounded para=
meter
pack expansion</b><br>
<br>
Thanks<br>
<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 02:15 PM, George
Makrydakis wrote:<br>
</div>
<blockquote cite=3D"mid:53832250.6090504@gmail.com" type=3D"cite">
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
There is also another couple of=C2=A0 issues to note here related to
both naming and other semantics asides my previous email.<br>
<br>
Let's take naming first. David Krauss writes in another message on
this thread:<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 12:12 PM, David Krauss
wrote:</div>
<blockquote type=3D"cite">The name might be confusing. I would
recommend calling it something more like non-dependent pack
patterns, or pack-like repetition (PLR has a ring to it).</blockquo=
te>
<br>
What Maurice Bos proposes is actually *bounded expansion
unpacking* over *unbounded expansion* which is the current modus
operandi of the ellipsis-only unpack operator. I think that given
we are talking about expansion, the ellipsis unpack operator
should identify unbounded pack expansion while the ...[N]
(ellipsis-subscript?) operator should identify bounded pack
expansion. <br>
<br>
Though repetition can be obtained through expansion, the two are
not the same thing since said ...[] operator can homeomorphically
deal with type parameters, non type - parameters and template
template parameters alike.<br>
<br>
On to another thing now, let's think of the following syntax:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D=
"color:#898887;">/*</span>
<span style=3D"color:#898887;"> * This is fictional syntax right now, for s=
tudy purposes</span>
<span style=3D"color:#898887;"> * and N,K,M are constant expressions...</sp=
an>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b><<b>typename</b>...[N] A1, <b>typename</b>...[K] A2, <b>t=
ypename</b>...[M] A3>
<b>struct</b> example0 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
How should combination of N,K,M into a nested function</span>
<span style=3D"color:#898887;"> * or class template be treated? </span>=
<span style=3D"color:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>typename</b>...> <b>class</b>..=
..[N] T1>
<b>struct</b> example1 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0 </span><span style=3D"color:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>typename</b>...[K]> <b>class</b=
>...[N] T1>
<b>struct</b> example2 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0, additional one level of nesting </span><span style=3D"co=
lor:#898887;">*/</span>
};
<b>template</b><<b>template</b><<b>template</b><<b>typename</b>...=
[M]> <b>class</b>...[K]> <b>class</b>...[N] T1>
<b>struct</b> example3 {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
same as example0, two levels of nesting with TTP </span><span style=3D"col=
or:#898887;">*/</span>
};
</pre>
The unbounded unpack operator (ellipsis) has some interesting
combinatorial properties when unpacking where multiple parameter
packs are used in combination. Which should be the syntax for such
occasions?<br>
<br>
On to a third point but important point, should there be a rule
when matching occurs between bounded and unbounded pack expansion
using the ellipsis-subscript operator when the following two
signatures are met?<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D=
"color:#898887;">/*</span>
<span style=3D"color:#898887;"> * This is fictional syntax right now, for t=
he Bos draft proposal.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
struct metamonger {
<b>template</b><<b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> bounded pack e=
xpansion, would be better with Args...[N] </span><span style=3D"color:#8988=
87;">*/</span>
}
<b>template</b><<b>typename</b>... Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> unbounded pack=
expansion </span><span style=3D"color:#898887;">*/</span>
}<span style=3D"color:#0057ae;"></span><span style=3D"color:#898887;"></spa=
n><span style=3D"color:#898887;"></span><span style=3D"color:#898887;"></sp=
an>
<span style=3D"color:#898887;">/*</span>
<span style=3D"color:#898887;"> * The problem is obvious, for when sizeof..=
..(Args) =3D N this should</span>
<span style=3D"color:#898887;"> * be considered ambiguous, if only it were =
that simple...</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
</pre>
I do not think that this is a simple case because it would force
the programmer to again use sfinae or tag dispatching to make sure
that there is no conflict when such an occasion is met. There has
to be some sort of priority here when used with function templates
or this is going to require the programmer to resort to amending
the code for when sizeof..(Args) =3D N. Not using ellipsis-subscript
to differentiate from the ellipsis only parameter unpacking (aka
unbounded pack expansion) is problematic as well for defining such
priority.<br>
<br>
Then there is another thing about whether or not we should be
accepting multidimensional ellipsis subscript operators in this
case, for mixing bounded and unbounded parameter pack expansion:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D=
"color:#898887;">/*</span><span style=3D"color:#898887;"> in this example, =
N and K are decided </span><span style=3D"color:#898887;">*/</span>
<b>template</b><std::size_t N, std::size_t K, <b>typename</b>...[N][K] A=
rgs>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting </span><span style=3D"color:#898887=
;">*/</span>
}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> in =
this example, N K are fixed </span><span style=3D"color:#898887;">*/</span>
<b>template</b><<b>typename</b>...[N][K] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting, especially if Args are not of the =
same type </span><span style=3D"color:#898887;">*/</span>
}</pre>
<br>
This can also lead to the function type signature collision as
well with unbound parameter pack expansion. It also makes evident
why during unpacking, ellipsis-subscript should be reused instead
of ellipsis alone.<br>
<br>
Lots of other things to say, but for the time being I cut it here.<br=
>
<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 12:36 PM, George
Makrydakis wrote:<br>
</div>
<blockquote
cite=3D"mid:8cdcc577-65a8-48a5-89f5-0b03c2bdc23c@email.android.com"
type=3D"cite">
<p dir=3D"ltr">This has significant consequences in enhancing the
readability of complex sfinae-heavy template metaprogramming
by making pattern matching through tag dispatching easier when
it comes to function templates. It would also allow for class
template partial specializations to factor out sfinae uses in
the type parameters used in a given partial specialization
through the evaluation of N.</p>
<p dir=3D"ltr">Is there a reason why you would not be able to use
template template parameters as well directly (without
wrapping them with a class template) with this syntax? I do
not see them mentioned or in the examples of your current
draft. They too make an important computational construct in
template metaprogramming.</p>
<p dir=3D"ltr">Overall, I think that metaprogrammers would be
delighted by your proposal. Also, it does not require any
previous code to be altered if introduced into the standard.
Simple and dazzling.</p>
<br>
<br>
<div class=3D"gmail_quote">On May 26, 2014 11:48:59 AM EEST,
Maurice Bos <<a moz-do-not-send=3D"true"
href=3D"http://m-ou.se">m-ou.se</a>@m-ou.se> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<pre class=3D"k9mail">Hi!
Here's the draft for my proposal: <a moz-do-not-send=3D"true" href=3D"http:=
//random.m-ou.se/fspp.html">http://random.m-ou.se/fspp.html</a>
Feedback is greatly appreciated.
Thanks!
-Maurice-
</pre>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000807020200040905060406--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 15:51:13 +0800
Raw View
--Apple-Mail=_AD89F35D-1C84-4698-8B13-82554C4C13D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-26, at 7:15 PM, George Makrydakis <irrequietus@gmail.com> wrote:
> There is also another couple of issues to note here related to both nami=
ng and other semantics asides my previous email.
>=20
> Let's take naming first. David Krauss writes in another message on this t=
hread:
>=20
> On 05/26/2014 12:12 PM, David Krauss wrote:
>> The name might be confusing. I would recommend calling it something more=
like non-dependent pack patterns, or pack-like repetition (PLR has a ring =
to it).
>=20
> What Maurice Bos proposes is actually *bounded expansion unpacking* over =
*unbounded expansion* which is the current modus operandi of the ellipsis-o=
nly unpack operator. I think that given we are talking about expansion, the=
ellipsis unpack operator should identify unbounded pack expansion while th=
e ...[N] (ellipsis-subscript?) operator should identify bounded pack expans=
ion.=20
>=20
> Though repetition can be obtained through expansion, the two are not the =
same thing since said ...[] operator can homeomorphically deal with type pa=
rameters, non type - parameters and template template parameters alike.
Can you explain again without the word "homeomorphically," or perhaps give =
an example that is not repetition (i.e. where the items of the expansion ar=
e different)? If there is no unexpanded pack in the pattern, then I don't s=
ee where a difference may be introduced.
> The unbounded unpack operator (ellipsis) has some interesting combinatori=
al properties when unpacking where multiple parameter packs are used in com=
bination. Which should be the syntax for such occasions?
The size of the pack is part of its declaration, but I don't see how this i=
s special. A combinatorial explosion can only happen if you nest expansions=
, which doesn't usually happen.
Also, note that template< int ... i, typename ... t > is illegal despite be=
ing unambiguous. I think that sequences of packs, even bounded ones, might =
wait for a later proposal. If it is allowed, the bound will sometimes be de=
duced and sometimes not.
> On to a third point but important point, should there be a rule when matc=
hing occurs between bounded and unbounded pack expansion using the ellipsis=
-subscript operator when the following two signatures are met?
I don't see why a fixed-length pack shouldn't behave the same as its expans=
ion, i.e. as if it were a non-pack sequence of declarations.
> /*
> * This is fictional syntax right now, for the Bos draft proposal.
> */
>=20
> struct metamonger {
> template<typename...[N] Args>
> void function(Args...) { /* bounded pack expansion, would be better with =
Args...[N] */
Re the comment: no, ...[N] would not expand the pack Args. What's the point=
of adding the bound when it can only have one value, which is already spec=
ified nearby?
> }
>=20
> template<typename... Args>
> void function(Args...) { /* unbounded pack expansion */
> }
>=20
> /*
> * The problem is obvious, for when sizeof...(Args) =3D N this should
> * be considered ambiguous, if only it were that simple...
> */
> I do not think that this is a simple case because it would force the prog=
rammer to again use sfinae or tag dispatching to make sure that there i=
s no conflict when such an occasion is met.
Simply don't do that. PLR is a shortcut to repetitive parameter declaration=
s, not a paradigm shift. If a sequence of declarations won't work, then the=
PLR won't either.
> There has to be some sort of priority here when used with function templa=
tes or this is going to require the programmer to resort to amending the co=
de for when sizeof..(Args) =3D N. Not using ellipsis-subscript to different=
iate from the ellipsis only parameter unpacking (aka unbounded pack expansi=
on) is problematic as well for defining such priority.
>=20
> Then there is another thing about whether or not we should be accepting m=
ultidimensional ellipsis subscript operators in this case, for mixing bound=
ed and unbounded parameter pack expansion:
This hasn't been proposed. It makes no sense, as we do not currently have p=
acks of packs. It looks like you would accomplish the same with [N*K], alth=
ough the example doesn't show usage.
> /* in this example, N and K are decided */
> template<std::size_t N, std::size_t K, typename...[N][K] Args>
> void function(Args...[N][K]) {
> /* this is where it gets VERY interesting */
> }
>=20
> /* in this example, N K are fixed */
> template<typename...[N][K] Args>
> void function(Args...[N][K]) {
> /* this is where it gets VERY interesting, especially if Args are not=
of the same type */
> }
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_AD89F35D-1C84-4698-8B13-82554C4C13D6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–26, at 7:15 PM, George Makrydakis <<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
There is also another couple of issues to note here related to bo=
th
naming and other semantics asides my previous email.<br>
<br>
Let's take naming first. David Krauss writes in another message on
this thread:<br>
<br>
<div class=3D"moz-cite-prefix">On 05/26/2014 12:12 PM, David Krauss
wrote:</div>
<blockquote type=3D"cite">The name might be confusing. I would
recommend calling it something more like non-dependent pack
patterns, or pack-like repetition (PLR has a ring to it).</blockquote=
>
<br>
What Maurice Bos proposes is actually *bounded expansion unpacking*
over *unbounded expansion* which is the current modus operandi of
the ellipsis-only unpack operator. I think that given we are talking
about expansion, the ellipsis unpack operator should identify
unbounded pack expansion while the ...[N] (ellipsis-subscript?)
operator should identify bounded pack expansion. <br>
<br>
Though repetition can be obtained through expansion, the two are not
the same thing since said ...[] operator can homeomorphically deal
with type parameters, non type - parameters and template template
parameters alike.<br></div></blockquote><div><br></div><div>Can you exp=
lain again without the word “homeomorphically,” or perhaps give=
an example that is not repetition (i.e. where the items of the expansion a=
re different)? If there is no unexpanded pack in the pattern, then I don&rs=
quo;t see where a difference may be introduced.</div><br><blockquote type=
=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">The unbounded unpack op=
erator (ellipsis) has some interesting
combinatorial properties when unpacking where multiple parameter
packs are used in combination. Which should be the syntax for such
occasions?</div></blockquote><div><br></div><div>The size of the pack i=
s part of its declaration, but I don’t see how this is special. A com=
binatorial explosion can only happen if you nest expansions, which doesn&rs=
quo;t usually happen.</div><div><br></div><div>Also, note that <font f=
ace=3D"Courier">template< int ... i, typename ... t ></font> is =
illegal despite being unambiguous. I think that sequences of packs, even bo=
unded ones, might wait for a later proposal. If it is allowed, the bound wi=
ll sometimes be deduced and sometimes not.</div><blockquote type=3D"cite"><=
div text=3D"#000000" bgcolor=3D"#FFFFFF"></div></blockquote><br><blockquote=
type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
=20
On to a third point but important point, should there be a rule when
matching occurs between bounded and unbounded pack expansion using
the ellipsis-subscript operator when the following two signatures
are met?<br></div></blockquote><div><br></div><div>I don’t see wh=
y a fixed-length pack shouldn’t behave the same as its expansion, i.e=
.. as if it were a non-pack sequence of declarations.</div><blockquote type=
=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 2=
55); position: static; z-index: auto;"><span style=3D"color:#898887;">/*</s=
pan>
<span style=3D"color:#898887;"> * This is fictional syntax right now, for t=
he Bos draft proposal.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
struct metamonger {
<b>template</b><<b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> bounded pack e=
xpansion, would be better with Args...[N] </span><span style=3D"color:#8988=
87;">*/</span>
</pre></div></blockquote><div>Re the comment: no, <font face=3D"Courier">..=
..[N]</font> would not expand the pack Args. What’s the point of addin=
g the bound when it can only have one value, which is already specified nea=
rby?</div><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFF=
F"><pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 25=
5); position: static; z-index: auto;">}
<b>template</b><<b>typename</b>... Args>
<span style=3D"color:#0057ae;">void</span> function(Args...) { <span style=
=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> unbounded pack=
expansion </span><span style=3D"color:#898887;">*/</span>
}<span style=3D"color:#0057ae;"></span><span style=3D"color:#898887;"></spa=
n><span style=3D"color:#898887;"></span><span style=3D"color:#898887;"></sp=
an>
<span style=3D"color:#898887;">/*</span>
<span style=3D"color:#898887;"> * The problem is obvious, for when sizeof..=
..(Args) =3D N this should</span>
<span style=3D"color:#898887;"> * be considered ambiguous, if only it were =
that simple...</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
</pre>
I do not think that this is a simple case because it would force the
programmer to again use sfinae or tag dispatching to make sure that
there is no conflict when such an occasion is met.</div></blockquote><d=
iv><br></div><div>Simply don’t do that. PLR is a shortcut to repetiti=
ve parameter declarations, not a paradigm shift. If a sequence of declarati=
ons won’t work, then the PLR won’t either.</div><br><blockquote=
type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF"> There has to be
some sort of priority here when used with function templates or this
is going to require the programmer to resort to amending the code
for when sizeof..(Args) =3D N. Not using ellipsis-subscript to
differentiate from the ellipsis only parameter unpacking (aka
unbounded pack expansion) is problematic as well for defining such
priority.<br>
<br>
Then there is another thing about whether or not we should be
accepting multidimensional ellipsis subscript operators in this
case, for mixing bounded and unbounded parameter pack expansion:<br></d=
iv></blockquote><div><br></div>This hasn’t been proposed. It makes no=
sense, as we do not currently have packs of packs. It looks like you would=
accomplish the same with <font face=3D"Courier">[N*K]</font>, although the=
example doesn’t show usage.<br><blockquote type=3D"cite"><div text=
=3D"#000000" bgcolor=3D"#FFFFFF">
=20
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 2=
55); position: static; z-index: auto;"><span style=3D"color:#898887;">/*</s=
pan><span style=3D"color:#898887;"> in this example, N and K are decided </=
span><span style=3D"color:#898887;">*/</span>
<b>template</b><std::size_t N, std::size_t K, <b>typename</b>...[N][K] A=
rgs>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting </span><span style=3D"color:#898887=
;">*/</span>
}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> in =
this example, N K are fixed </span><span style=3D"color:#898887;">*/</span>
<b>template</b><<b>typename</b>...[N][K] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
this is where it gets VERY interesting, especially if Args are not of the =
same type </span><span style=3D"color:#898887;">*/</span>
}</pre>
</div></blockquote></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_AD89F35D-1C84-4698-8B13-82554C4C13D6--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 27 May 2014 11:41:58 +0300
Raw View
On 27 May 2014 10:51, David Krauss <potswa@gmail.com> wrote:
> Also, note that template< int ... i, typename ... t > is illegal despite
> being unambiguous. I think that sequences of packs, even bounded ones, might
> wait for a later proposal. If it is allowed, the bound will sometimes be
> deduced and sometimes not.
I don't follow. What exactly is illegal in it? Are you talking about
the proposal
or the status quo of the standard? The standard allows it.
--
---
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/.
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Tue, 27 May 2014 03:52:59 -0700 (PDT)
Raw View
------=_Part_1_25320078.1401187980107
Content-Type: text/plain; charset=UTF-8
I have thought of a problem related (but not the same)
What about using '{}' syntax in the instantiation of the template, but
instead of std::initializer_list of values, it is a "initializer list of
types" ?
template<typename ...T, typename ... U, int... P>
class X { };
X<{ int, const char* }, { char, std::string, int }, {10,20,30,40, -1}> x;
this way you can statically check if the sizes are the same,asking
sizeof(T)..., sizeof(U)..., sizeof(P)... if you need.
--
---
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_1_25320078.1401187980107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I have thought of a problem related (but not the same=
)</div><div><br></div><div>What about using '{}' syntax in the instantiatio=
n of the template, but instead of std::initializer_list of values, it =
is a "initializer list of types" ?</div><div><br></div>template<typename=
...T, typename ... U, int... P> <div>class X { };</div><div><br></=
div><div>X<{ int, const char* }, { char, std::string, int }, {10,20,30,4=
0, -1}> x;</div><div><br></div><div>this way you can statically check if=
the sizes are the same,asking sizeof(T)..., sizeof(U)..., sizeof(P)... if =
you need.</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1_25320078.1401187980107--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 20:31:37 +0800
Raw View
On 2014-05-27, at 4:41 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 27 May 2014 10:51, David Krauss <potswa@gmail.com> wrote:
>> Also, note that template< int ... i, typename ... t > is illegal despite
>> being unambiguous. I think that sequences of packs, even bounded ones, might
>> wait for a later proposal. If it is allowed, the bound will sometimes be
>> deduced and sometimes not.
>
>
> I don't follow. What exactly is illegal in it? Are you talking about
> the proposal
> or the status quo of the standard? The standard allows it.
Not in the context of the example. Such an argument list requires the second pack to be deduced.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 20:33:53 +0800
Raw View
On 2014-05-27, at 8:31 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-05-27, at 4:41 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
>> On 27 May 2014 10:51, David Krauss <potswa@gmail.com> wrote:
>>> Also, note that template< int ... i, typename ... t > is illegal despite
>>> being unambiguous. I think that sequences of packs, even bounded ones, might
>>> wait for a later proposal. If it is allowed, the bound will sometimes be
>>> deduced and sometimes not.
>>
>>
>> I don't follow. What exactly is illegal in it? Are you talking about
>> the proposal
>> or the status quo of the standard? The standard allows it.
>
> Not in the context of the example. Such an argument list requires the second pack to be deduced.
Er, such a template parameter list. It would be allowed in a function template or class template partial specialization, given the right function parameter list or partial specialization argument list.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 27 May 2014 16:41:57 +0300
Raw View
On 27 May 2014 15:33, David Krauss <potswa@gmail.com> wrote:
>>> On 27 May 2014 10:51, David Krauss <potswa@gmail.com> wrote:
>>>> Also, note that template< int ... i, typename ... t > is illegal despite
>>>> being unambiguous. I think that sequences of packs, even bounded ones, might
>>>> wait for a later proposal. If it is allowed, the bound will sometimes be
>>>> deduced and sometimes not.
>>> I don't follow. What exactly is illegal in it? Are you talking about
>>> the proposal
>>> or the status quo of the standard? The standard allows it.
>> Not in the context of the example. Such an argument list requires the second pack to be deduced.
> Er, such a template parameter list. It would be allowed in a function template or class template partial specialization, given the right function parameter list or partial specialization argument list.
Indeed. It _is_ allowed in a function template, and works fine currently.
--
---
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/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Tue, 27 May 2014 20:24:19 +0200
Raw View
2014-05-26 11:09 GMT+02:00 Stack Machine <stackmachine@hotmail.com>:
> Why aren't empty parameter packs allowed?
They are.
--
---
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/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Tue, 27 May 2014 20:24:24 +0200
Raw View
This feature should work with template template parameters as well,
yes. If you have a good example of a use case, that would be great.
2014-05-26 11:36 GMT+02:00 George Makrydakis <irrequietus@gmail.com>:
> This has significant consequences in enhancing the readability of complex
> sfinae-heavy template metaprogramming by making pattern matching through tag
> dispatching easier when it comes to function templates. It would also allow
> for class template partial specializations to factor out sfinae uses in the
> type parameters used in a given partial specialization through the
> evaluation of N.
>
> Is there a reason why you would not be able to use template template
> parameters as well directly (without wrapping them with a class template)
> with this syntax? I do not see them mentioned or in the examples of your
> current draft. They too make an important computational construct in
> template metaprogramming.
>
> Overall, I think that metaprogrammers would be delighted by your proposal.
> Also, it does not require any previous code to be altered if introduced into
> the standard. Simple and dazzling.
>
>
>
> On May 26, 2014 11:48:59 AM EEST, Maurice Bos <m-ou.se@m-ou.se> wrote:
>>
>> Hi!
>>
>> Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>>
>> Feedback is greatly appreciated.
>>
>> Thanks!
>>
>> -Maurice-
--
---
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/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Tue, 27 May 2014 20:24:28 +0200
Raw View
Using void foo(int...[]) as a shorthand could make sense, depending on
whether void foo(auto) will be allowed. (And then also void
foo(auto...[]).) I think this should be left to a separate proposal,
though.
I'm not comparing it against a std::tuple<int, int, int>, I'm
comparing it to just three ints. the relationship between f(int, int,
int), f(int[3]) and f(std::array<int,3>) won't change at all.
f(int...[3]) is just a convenient way to write f(int, int, int).
2014-05-26 12:34 GMT+02:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> Maurice,
>
> What about, in addition to:
>
> template<size_t N> void f(int...[N]);
>
> you propose:
>
> void f(int...[]);
>
> The size of the pack can be determined with sizeof... as usual. The
> trailing empty square brackets disambiguate from the C-style variable
> arguments ellipsis. The presence of the pack parameter in the declarator
> implcitly turns the declaration into a template declaration. You might want
> to take a look at the latest Concept spec for ideas about this kind of
> implicit template declaration machinery.
>
> Also, normally sequences of homogeneous type are represented with arrays and
> array-like containers (like std::array). You should consider carefully the
> relationship between arrays and your proposal. I see in your first three
> use cases you are comparing against std::tuple<int, int, int> and not int[3]
> nor std::array<int,3>.
>
> That is, I think you should discuss the relationship between f(int, int,
> int), f(int[3]) and f(std::array<int,3>)
>
> Regards,
> Andrew.
>
>
>
>
>
>
> On Mon, May 26, 2014 at 10:48 AM, Maurice Bos <m-ou.se@m-ou.se> wrote:
>>
>> Hi!
>>
>> Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>>
>> Feedback is greatly appreciated.
>>
>> Thanks!
>>
>> -Maurice-
>>
>> --
>>
>> ---
>> 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/.
>
>
> --
>
> ---
> 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/.
--
---
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/.
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Tue, 27 May 2014 20:28:04 +0200
Raw View
Being able to explicitly write packs with their contents could be a
separate proposal. Maybe we can at some point allow things like this:
using... P = <int, float, char>; foo(P(0)...); etc. Then your example
would be X<<int, const char*>, <char, std::string, int>,
<10,20,30,40,-1>> x;
But that's not part of this proposal.
2014-05-27 12:52 GMT+02:00 Cleiton Santoia <cleitonsantoia@gmail.com>:
> I have thought of a problem related (but not the same)
>
> What about using '{}' syntax in the instantiation of the template, but
> instead of std::initializer_list of values, it is a "initializer list of
> types" ?
>
> template<typename ...T, typename ... U, int... P>
> class X { };
>
> X<{ int, const char* }, { char, std::string, int }, {10,20,30,40, -1}> x;
>
> this way you can statically check if the sizes are the same,asking
> sizeof(T)..., sizeof(U)..., sizeof(P)... if you need.
>
> --
>
> ---
> 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/.
--
---
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/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 28 May 2014 21:02:01 +0200
Raw View
--bcaec50e5ea587538f04fa7a7287
Content-Type: text/plain; charset=UTF-8
On Tue, May 27, 2014 at 8:24 PM, Maurice Bos <m-ou.se@m-ou.se> wrote:
> I'm not comparing it against a std::tuple<int, int, int>, I'm
> comparing it to just three ints. the relationship between f(int, int,
> int), f(int[3]) and f(std::array<int,3>) won't change at all.
> f(int...[3]) is just a convenient way to write f(int, int, int).
>
While the function type of f(int...[3]) and f(int, int, int) are identical,
the function definition is not. In particular the f(int...[3]) definition
introduces a single local name that denotes an entity that represents a
sequence of 3 ints (a pack). The f(int, int, int) definition introduces
three separate names. The f(int...[3]) definition is more similar in this
regard to the f(int[3]) and f(std::array<int,3>) definitions which both
introduce a single local name for an entity that denotes a sequence of
three ints (the two entities are a pointer to the first element of a these
three ints in memory, and a std::array<int,3> value, respectively).
What I am suggesting is that you analyze this redundancy and relationship
carefully. For example, under what specific use case would you use
f(int...[3]) rather than f(std::array<int,3>), and visa versa?
Performance-wise they are identical I think, and they can be called
similarly with f(1,2,3} and f({1,2,3}). Is the only difference getting rid
of those curly braces in the function call? Or is there more going on here
we should notice?
--
---
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/.
--bcaec50e5ea587538f04fa7a7287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, May 27, 2014 at 8:24 PM, Maurice Bos <span dir=3D"=
ltr"><<a href=3D"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m-ou.=
se</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
I'm not comparing it against a std::tuple<int, int, int>, I'm=
<br>
comparing it to just three ints. the relationship between f(int, int,<br>
int), f(int[3]) and f(std::array<int,3>) won't change at all.<br>
f(int...[3]) is just a convenient way to write f(int, int, int).<br></block=
quote><div><br></div><div>While the function type of f(int...[3]) and f(int=
, int, int) are identical, the function definition is not.=C2=A0 In particu=
lar the f(int...[3]) definition introduces a single local name that denotes=
an entity that represents a sequence of 3 ints (a pack).=C2=A0 The f(int, =
int, int) definition introduces three separate names.=C2=A0 The f(int...[3]=
) definition is more similar in this regard to the f(int[3]) and f(std::arr=
ay<int,3>) definitions which both introduce a single local name for a=
n entity that denotes a sequence of three ints (the two entities are a poin=
ter to the first element of a these three ints in memory, and a std::array&=
lt;int,3> value, respectively). <br>
<br></div><div>What I am suggesting is that you analyze this redundancy and=
relationship carefully.=C2=A0 For example, under what specific use case wo=
uld you use f(int...[3]) rather than f(std::array<int,3>), and visa v=
ersa?=C2=A0 Performance-wise they are identical I think, and they can be ca=
lled similarly with f(1,2,3} and f({1,2,3}).=C2=A0 Is the only difference g=
etting rid of those curly braces in the function call?=C2=A0 Or is there mo=
re going on here we should notice?<br>
<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec50e5ea587538f04fa7a7287--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 29 May 2014 08:04:24 +0800
Raw View
On 2014-05-29, at 3:02 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> What I am suggesting is that you analyze this redundancy and relationship carefully. For example, under what specific use case would you use f(int...[3]) rather than f(std::array<int,3>), and visa versa? Performance-wise they are identical I think,
The generic ABI passes structures up to two machine words or two members in registers. So the array would be passed on the stack whereas the pack would be passed in registers.
> and they can be called similarly with f(1,2,3} and f({1,2,3}). Is the only difference getting rid of those curly braces in the function call? Or is there more going on here we should notice?
A fixed-size pack in a template argument list is effectively a compile-time array. Currently such things have to be modeled using SFINAE to restrict a parameter pack.
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 29 May 2014 03:05:22 +0300
Raw View
This is a multi-part message in MIME format.
--------------070501050405000204020208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sorry for the delay.
About certain examples already used, you have already provided and been
provided a reply as to their correctness in the following quote:
On 05/27/2014 04:41 PM, Ville Voutilainen wrote:
> On 27 May 2014 15:33, David Krauss <potswa@gmail.com> wrote:
>>>> On 27 May 2014 10:51, David Krauss <potswa@gmail.com> wrote:
>>>>> Also, note that template< int ... i, typename ... t > is illegal despite
>>>>> being unambiguous. I think that sequences of packs, even bounded ones, might
>>>>> wait for a later proposal. If it is allowed, the bound will sometimes be
>>>>> deduced and sometimes not.
>>>> I don't follow. What exactly is illegal in it? Are you talking about
>>>> the proposal
>>>> or the status quo of the standard? The standard allows it.
>>> Not in the context of the example. Such an argument list requires the second pack to be deduced.
>> Er, such a template parameter list. It would be allowed in a function template or class template partial specialization, given the right function parameter list or partial specialization argument list.
> Indeed. It _is_ allowed in a function template, and works fine currently.
>
Now to other things. As I have addressed in previous emails and Andrew
Tomazos did in one of his replies, the problems begin with this proposal
because of conflicting semantics between definition/declaration and
resulting instantiation. We have not been provided an answer by Maurice
for that. However do note that his is a very, very early draft asking
for comments. The *major problem* is when we are trying to shoehorn a
lot of unrelated things to parameter packs and I will just focus on this
from Maurice's proposal:
|*template*<*typename*...[2] Args>
void foo(Args... args)|
Type parameters, non type parameters and template template parameters
(eventually) using this syntax? I feel that although this is an exciting
proposal (for me), the current draft stage does not do it justice. I
will present an alternative in the following segments that kind of says
something about Maurice Bos' proposal but expands the notion to a level
similar to what the EWG should, where they take a lot of other things at
heart other than shorthands to certain kinds of notation. Let me also
begin with saying that one *can implement "fixed packs" at a template
meta-programming library level in a variety of ways.* Now, I will be
using some specific terms as to what "packs" are if the notion should be
extended to include "fixed" size. Let's proceed:
1. *typename*...[N] Args -> bounded pack (expand until N types or match to any number < N)
2. *typename* [N] Args -> finite pack (expand or match to exactly N types)
3. *typename*... Args -> unbounded pack (the parameter pack in C++11, C++14)
Without malice, I disagree with the term "pack like repetition" you
propose because it is a limited case of a far more generic set. A
conceptually simple reason of why pack-like repetition is an unfortunate
term can be seen when: *typename...[N]* is used:
long,char,short <--*not* a"repetition", but an expansion
char,char,long <--*not* a"repetition", but an expansion
long,short,char <--*not* a"repetition", but an expansion
...
char,char,char <--- repetition of a single type, still an expansion of a pack
long,long,long <--- repetition of a single type, still an expansion of a pack
Therefore: *typename...[N]* includes both repetitive and non-repetitive
expansion and you cannot get around the repercussions no matter what you
do. Take notice now of the following scenario where multidimensionality
is assumed (this is not in Maurice's proposal, I am considering it for
theoretical and demonstrative purposes):
*template*<*typename*...[3][2] Args>
void function(Args...[N][K])
{}
When the pack is: int,int,int:
*typename*...[3] Args ->int,int,int
*typename*...[3][2] Args ->int,int,int,int,int,int
the effect numerically is equal to N*M, meaning typename...[6] and you
have the repetition of a *SINGLE type*.
When the pack is: int,char,long:
*typename*...[3] Args ->int,char,long
*typename*...[3][2] Args ->int,char,long,int,char,long,int,char,long
The effect is numerically equal to N*M, meaning typename...[6] but you
have the repetition of a *type PATTERN*. This is not the same thing
qualitatively, despite quantitatively I would not disagree with you. In
need of malice, one could go on if we consider eventual FINITE and
BOUNDED pack expansion semantics, note because I am proposing them but
because there can be such a consideration (which has some interesting
repercussions for code generation through type calculations):
*typename*...[3]...[2] -> .....
*typename* [3][2] -> .....
*typename* ...[3][2] -> .....
*typename* [3]...[2] -> .....
Your advise of "simply don't do it" seems to not be covering all bases
of the actual problem here. Also, none of this is in a standard or a
proposal yet, so one has to consider the most generic case for the sake
of argument. You might have also understood by now of why I used the
term "homeomorphically", referring to equivalences met in topology. Not
the same thing, but far more apt (to my eyes) than "analogous" and similar.
To address multiple concerns at once and offer food for thought, I will
continue with big block of code segment where various scenarios are
involved in a far more expanded version of Maurice's proposal but
focusing just on function templates for the sake of initial examples. A
final paragraph follows with more analysis of what is presented. If we
are to revise parameter pack expansions in variadic templates (both
function and class) responsibly, we have to come to terms what placing
arbitrary bounds on parameter pack
expansion sets means in several settings of the language itself. It is
_*far too easy to get carried away creatively*____*with pack expansion
revisions without understanding the consequences*_ and I strongly
believe that people in the EWG know that. Especially those who have
reality altering powers due to template meta-programming stoicism.
/******************************************************************************
**WARNING*: theoretical, non currently standard code follows. *
******************************************************************************/
/* *NOTE*: What happens when sizeof...(Args) = N of another function template
* where "fixed packs" are used?
*
*/
*template*<*typename*...[N] Args>
void function(Args...[N])
{}
/* *NOTE*: There is only one N used here for both bounded parameter packs.
**NOTE*: This is an example of BOUNDED PACK EXPANSION.
**NOTE*: This would result in ambiguous resolution with valid C++11, C++14
* variadic function templates with same name for ANY GIVEN N.
*
*/
*template*<*template*<*typename*...[N]>*class* Type_T
,*typename*...[N] Args>
void function(Type_T<Args...[N]>)
{}
/* *NOTE*: There are two parameter packs K, N where N <= K or this should be
* removed from the resolution set.
**NOTE*: This is an example of BOUNDED PACK EXPANSION.
**NOTE*: This would result in ambiguous resolution with valid C++11, C++14
* variadic function templates with same name for a set of N,K.
*/
*template*<*template*<*typename*...[K]>*class* Type_T
,*typename*...[N] Args>
void function(Type_T<Args...[N]>)
{}
/* *NOTE*: There is only one N used here and the pack has to be of exactly N
* type parameters.
**NOTE*: This is an example of FIXED PACK EXPANSION.
**NOTE*: This would result in ambiguous resolution with valid C++11, C++14
* variadic function templates with same name for a SPECIFIC N.
*/
*template*<*template*<*typename* [N]>*class* Type_T
,*typename* [N] Args>
void function(Type_T<Args [N]>)
{}
/* *NOTE*: it is obvious that we are talking about bounded pack expansion here,
* but do notice the combinatorial properties of the operator, which
* are completely analogous as with the current pack parameter expansion.
*
* Look at how easy this can lead to conflicts for a specific set of N,K,M
* values with a valid variadic function template of the same name if
* there is no priority overriding rule:
*/
*template*<*template*<*typename*...[N]>*class*...[M] Type_T
,*typename*...[K] Args >
void function(Type_T<Args...[K]>...[M])
{}
/* *NOTE*: Why zero "length" fixed packs are pointless.
**NOTE*: This would conflict with void function() {}.
*/
*template*<*typename*... [0]>
void function(*typename*... [0])
{}
/* *NOTE*: Another example, with "fixed" notation which has
* the same unfortunate problem.
*/
*template*<*typename* [0]>
void function(*typename* [0])
{}
In conclusion, while Maurice Bos' proposal is very worthy of meticulous
EWG scrutiny, *there are several problems with it*. It is too focused on
runtime ease without taking into consideration other problems it would
cause for such convenience. C++ is fortunately not Ruby. Some of my
previously unvoiced concerns are laid out, in view of the notation I
have however expanded upon in order to describe what those problems are:
The current proposal about ...[N] and ... does not specify if they have
different resolution priorities when conflicts occur for any or
specified N between the two. This leads to conflicts for instantiations
are hidden due to different declarative and/or definition semantics but
identical resulting type signatures for said instantiations. One of my
earlier emails implies that, Andrew Tomazos focuses on it as well on a
latter email.
1) The current proposal implies that *...[N]* resolves to a *fixed
N* but because of the semantics of the ... in variadic parameter
expansion*I propose that [N] without the ellipsis should be used for
FINITE pack expansion (exactly N) types required*.
2) When ...[N] is used, this should translate to BOUNDED pack
expansion, meaning that the type, non-type and template template type
parameters used should be up to a maximum of N. That is one point to
consider.
3) There can be no ...[0] or [0] used explicitely because of the
conflict described above. Cases like ...[1] and [1] would have
additional problems as explained in 1). "Simply don't do it" is
insufficient a reason if you intend to introduce things that can result
in conflicts when certain instantiations are produced through variadic
template manipulation as is done in C++11 and C++14 template
meta-programming.
4) We have not even begun to treat the relations of something like
this with partial specializations of class templates, friend function
template and class template resolutions (both with in class scope
definitions and non) and explicit template instantiations (where the
access specifier override behaviour can be of a pain).
5) Combinatorial properties of ... and ...[N] should behave
analogously or the amount of exceptions to certain combinations would
lead us to far too many conflicts.
6) If the proposal got presented at its current state without
resolving issues like the ones presented above, it would have extreme
difficulty to pass to a language core level.
7) Parameter pack "bounds" can grant C++ template meta-programming
powers like the ones found in typed template haskell or idris type
providers using a series of rather WIDELY UNKNOWN creative uses ofC++
template metaprogramming. It is off topic to discuss this in here.
I think that for the time being, I will expect a newer, better draft of
this proposal before commenting or replying further. I would not like to
end up writing another, long counter-proposal until this is properly
sorted out nor do I currently have the time for it (having the
motivation though may be detrimental). I do not like the fact that
Maurice's proposal is heavily "runtime" influenced.
George
--
---
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/.
--------------070501050405000204020208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Sorry for the delay.<br>
<br>
About certain examples already used, you have already provided and
been provided a reply as to their correctness in the following
quote:<br>
<br>
<div class=3D"moz-cite-prefix">On 05/27/2014 04:41 PM, Ville
Voutilainen wrote:<br>
</div>
<blockquote
cite=3D"mid:CAFk2RUY_+m+q1k_1wmmD_6ePt7QHqSp-HYRaboE4OVBQi696wQ@mail.gmail.=
com"
type=3D"cite">
<pre wrap=3D"">On 27 May 2014 15:33, David Krauss <a class=3D"moz-txt=
-link-rfc2396E" href=3D"mailto:potswa@gmail.com"><potswa@gmail.com></=
a> wrote:
</pre>
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">On 27 May 2014 10:51, David Krauss <a class=3D"m=
oz-txt-link-rfc2396E" href=3D"mailto:potswa@gmail.com"><potswa@gmail.com=
></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Also, note that template< int ... i, typena=
me ... t > is illegal despite
being unambiguous. I think that sequences of packs, even bounded ones, migh=
t
wait for a later proposal. If it is allowed, the bound will sometimes be
deduced and sometimes not.
</pre>
</blockquote>
<pre wrap=3D"">I don't follow. What exactly is illegal in it? A=
re you talking about
the proposal
or the status quo of the standard? The standard allows it.
</pre>
</blockquote>
<pre wrap=3D"">Not in the context of the example. Such an argumen=
t list requires the second pack to be deduced.
</pre>
</blockquote>
<pre wrap=3D"">Er, such a template parameter list. It would be allo=
wed in a function template or class template partial specialization, given =
the right function parameter list or partial specialization argument list.
</pre>
</blockquote>
<pre wrap=3D"">
Indeed. It _is_ allowed in a function template, and works fine currently.
</pre>
</blockquote>
<br>
Now to other things. As I have addressed in previous emails and
Andrew Tomazos did in one of his replies, the problems begin with
this proposal because of conflicting semantics between
definition/declaration and resulting instantiation. We have not been
provided an answer by Maurice for that. However do note that his is
a very, very early draft asking for comments. The <b>major problem</b>
is when we are trying to shoehorn a lot of unrelated things to
parameter packs and I will just focus on this from Maurice's
proposal:<br>
<br>
<code><b>template</b><<b>typename</b>...[2] Args><br>
void foo(Args... args)</code><br>
<br>
<br>
Type parameters, non type parameters and template template
parameters (eventually) using this syntax? I feel that although this
is an exciting proposal (for me), the current draft stage does not
do it justice. I will present an alternative in the following
segments that kind of says something about Maurice Bos' proposal but
expands the notion to a level similar to what the EWG should, where
they take a lot of other things at heart other than shorthands to
certain kinds of notation. Let me also begin with saying that one <b>ca=
n
implement "fixed packs" at a template meta-programming library
level in a variety of ways.</b> Now, I will be using some specific
terms as to what "packs" are if the notion should be extended to
include "fixed" size. Let's proceed:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#b08000;">1.</span> <b>typename</b>...[N] Args -> bounded pack (exp=
and until N types or match to any number < N)
<span style=3D"color:#b08000;">2.</span> <b>typename</b> [N] Args -> f=
inite pack (expand or match to exactly N types)
<span style=3D"color:#b08000;">3.</span> <b>typename</b>... Args -> u=
nbounded pack (the parameter pack in C++<span style=3D"color:#b08000;">11</=
span>, C++<span style=3D"color:#b08000;">14</span>)
</pre>
Without malice, I disagree with the term "pack like repetition" you
propose because it is a limited case of a far more generic set. A
conceptually simple reason of why pack-like repetition is an
unfortunate term can be seen when: <b>typename...[N]</b> is used:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#0057ae;"> long</span>, <span style=3D"color:#0057ae;">char</span>, <=
span style=3D"color:#0057ae;">short</span> <-- <b>not</b> a <span style=
=3D"color:#bf0303;">"repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">char</span>, <span style=3D"color:#0057ae;=
">char</span>, <span style=3D"color:#0057ae;">long</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">long</span>, <span style=3D"color:#0057ae;=
">short</span>, <span style=3D"color:#0057ae;">char</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
...
<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae;"=
>char</span>,<span style=3D"color:#0057ae;">char</span> <--- repetition =
of a single type, still an expansion of a pack
<span style=3D"color:#0057ae;">long</span>,<span style=3D"color:#0057ae;"=
>long</span>,<span style=3D"color:#0057ae;">long</span> <--- repetition =
of a single type, still an expansion of a pack</pre>
<br>
Therefore: <b>typename...[N]</b> includes both repetitive and
non-repetitive expansion and you cannot get around the repercussions
no matter what you do. Take notice now of the following scenario
where multidimensionality is assumed (this is not in Maurice's
proposal, I am considering it for theoretical and demonstrative
purposes):<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>template</b>&=
lt;<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=
=3D"color:#b08000;">2</span>] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...[N][K])
{}
</pre>
When the pack is: int,int,int:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>typename</b>.=
...[<span style=3D"color:#b08000;">3</span>] Args -> <span style=3D"co=
lor:#0057ae;">int</span>,<span style=3D"color:#0057ae;">int</span>,<span st=
yle=3D"color:#0057ae;">int</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"color:#0057ae;=
">int</span>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"color=
:#0057ae;">int</span>,<span style=3D"color:#0057ae;">int</span></pre>
<br>
the effect numerically is equal to N*M, meaning typename...[6] and
you have the repetition of a <b>SINGLE type</b>.<br>
<br>
When the pack is: int,char,long:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>typename</b>.=
...[<span style=3D"color:#b08000;">3</span>] Args -> <span style=3D"co=
lor:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</span>,<span s=
tyle=3D"color:#0057ae;">long</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"col=
or:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</span>,<span s=
tyle=3D"color:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</spa=
n>,<span style=3D"color:#0057ae;">long</span></pre>
<br>
The effect is numerically equal to N*M, meaning typename...[6] but
you have the repetition of a <b>type PATTERN</b>. This is not the
same thing qualitatively, despite quantitatively I would not
disagree with you. In need of malice, one could go on if we consider
eventual FINITE and BOUNDED pack expansion semantics, note because I
am proposing them but because there can be such a consideration
(which has some interesting repercussions for code generation
through type calculations):<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>typename</b>.=
...[<span style=3D"color:#b08000;">3</span>]...[<span style=3D"color:#b08000=
;">2</span>] -> .....
<b>typename</b> [<span style=3D"color:#b08000;">3</span>][<span style=3D"co=
lor:#b08000;">2</span>] -> .....
<b>typename</b> ...[<span style=3D"color:#b08000;">3</span>][<span style=3D=
"color:#b08000;">2</span>] -> .....
<b>typename</b> [<span style=3D"color:#b08000;">3</span>]...[<span style=3D=
"color:#b08000;">2</span>] -> .....</pre>
<br>
Your advise of "simply don't do it" seems to not be covering all
bases of the actual problem here. Also, none of this is in a
standard or a proposal yet, so one has to consider the most generic
case for the sake of argument. You might have also understood by now
of why I used the term "homeomorphically", referring to equivalences
met in topology. Not the same thing, but far more apt (to my eyes)
than "analogous" and similar.<br>
<br>
To address multiple concerns at once and offer food for thought, I
will continue with big block of code segment where various scenarios
are involved in a far more expanded version of Maurice's proposal
but focusing just on function templates for the sake of initial
examples. A final paragraph follows with more analysis of what is
presented. If we are to revise parameter pack expansions in variadic
templates (both function and class) responsibly, we have to come to
terms what placing arbitrary bounds on parameter pack<br>
expansion sets means in several settings of the language itself. It
is <u><b>far too easy to get carried away creatively</b></u><u> </u><u>=
<b>with
pack expansion revisions without understanding the consequences</b>=
</u>
and I strongly believe that people in the EWG know that. Especially
those who have reality altering powers due to template
meta-programming stoicism.<br>
<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span><span style=3D"color:#898887;">********************=
*********************************************************</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#ca9219;ba=
ckground:#451e1a;">WARNING</span></b><span style=3D"color:#898887;">: theor=
etical, non currently standard code follows. *</span>
<span style=3D"color:#898887;"> *******************************************=
**********************************</span><span style=3D"color:#898887;">*/<=
/span>
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: What happens when sizeof...(Args) =3D N of an=
other function template</span>
<span style=3D"color:#898887;"> * where "fixed packs" are used?</span=
>
<span style=3D"color:#898887;"> * </span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b><<b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Args...[N])
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: There is only one N used here for both bounde=
d parameter packs.</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This is =
an example of BOUNDED PACK EXPANSION.</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This wou=
ld result in ambiguous resolution with valid C++11, C++14</span>
<span style=3D"color:#898887;"> * variadic function templates with sa=
me name for ANY GIVEN N.</span>
<span style=3D"color:#898887;"> * </span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b>< <b>template</b><<b>typename</b>...[N]> <b>class</=
b> Type_T
, <b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Type_T<Args...[N]>=
;)
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: There are two parameter packs K, N where N &l=
t;=3D K or this should be</span>
<span style=3D"color:#898887;"> * removed from the resolution set.</s=
pan>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This is =
an example of BOUNDED PACK EXPANSION.</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This wou=
ld result in ambiguous resolution with valid C++11, C++14</span>
<span style=3D"color:#898887;"> * variadic function templates with sa=
me name for a set of N,K.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b>< <b>template</b><<b>typename</b>...[K]> <b>class</=
b> Type_T
, <b>typename</b>...[N] Args>
<span style=3D"color:#0057ae;">void</span> function(Type_T<Args...[N]>=
;)
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: There is only one N used here and the pack ha=
s to be of exactly N</span>
<span style=3D"color:#898887;"> * type parameters.</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This is =
an example of FIXED PACK EXPANSION.</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This wou=
ld result in ambiguous resolution with valid C++11, C++14</span>
<span style=3D"color:#898887;"> * variadic function templates with sa=
me name for a SPECIFIC N.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b>< <b>template</b><<b>typename</b> [N]> <b>class</b>=
Type_T
, <b>typename</b> [N] Args>
<span style=3D"color:#0057ae;">void</span> function(Type_T<Args [N]>)
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: it is obvious that we are talking about bound=
ed pack expansion here,</span>
<span style=3D"color:#898887;"> * but do notice the combinatorial pro=
perties of the operator, which</span>
<span style=3D"color:#898887;"> * are completely analogous as with th=
e current pack parameter expansion.</span>
<span style=3D"color:#898887;"> * </span>
<span style=3D"color:#898887;"> * Look at how easy this can lead to co=
nflicts for a specific set of N,K,M</span>
<span style=3D"color:#898887;"> * values with a valid variadic functio=
n template of the same name if</span>
<span style=3D"color:#898887;"> * there is no priority overriding rule=
:</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b>< <b>template</b><<b>typename</b>...[N]> <b>class</=
b>...[M] Type_T
, <b>typename</b>...[K] Args >
<span style=3D"color:#0057ae;">void</span> function(Type_T<Args...[K]>=
;...[M])
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: Why zero "length" fixed packs are pointless.<=
/span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: This wou=
ld conflict with void function() {}.</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b><<b>typename</b>... [<span style=3D"color:#b08000;">0</sp=
an>]>
<span style=3D"color:#0057ae;">void</span> function(<b>typename</b>... [<sp=
an style=3D"color:#b08000;">0</span>])
{}
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> </s=
pan><b><span style=3D"color:#81ca2d;background:#f7e6e6;">NOTE</span></b><sp=
an style=3D"color:#898887;">: Another example, with "fixed" notation which =
has</span>
<span style=3D"color:#898887;"> * the same unfortunate problem.</span=
>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b>template</b><<b>typename</b> [<span style=3D"color:#b08000;">0</span>=
]>
<span style=3D"color:#0057ae;">void</span> function(<b>typename</b> [<span =
style=3D"color:#b08000;">0</span>])
{}
</pre>
In conclusion, while Maurice Bos' proposal is very worthy of
meticulous EWG scrutiny, <b>there are several problems with it</b>.
It is too focused on runtime ease without taking into consideration
other problems it would cause for such convenience. C++ is
fortunately not Ruby. Some of my previously unvoiced concerns are
laid out, in view of the notation I have however expanded upon in
order to describe what those problems are:<br>
The current proposal about ...[N] and ... does not specify if they
have different resolution priorities when conflicts occur for any or
specified N between the two. This leads to conflicts for
instantiations are hidden due to different declarative and/or
definition semantics but identical resulting type signatures for
said instantiations. One of my earlier emails implies that, Andrew
Tomazos focuses on it as well on a latter email.<br>
<br>
1) The current proposal implies that <b>...[N]</b> r=
esolves to
a <b>fixed N</b> but because of the semantics of the ... in
variadic parameter expansion<b> I propose that [N] without the
ellipsis should be used for FINITE pack expansion (exactly N)
types required</b>.<br>
<br>
2) When ...[N] is used, this should translate to BOU=
NDED pack
expansion, meaning that the type, non-type and template template
type parameters used should be up to a maximum of N. That is one
point to consider. <br>
<br>
3) There can be no ...[0] or [0] used explicitely be=
cause of the
conflict described above. Cases like ...[1] and [1] would have
additional problems as explained in 1). "Simply don't do it" is
insufficient a reason if you intend to introduce things that can
result in conflicts when certain instantiations are produced through
variadic template manipulation as is done in C++11 and C++14
template meta-programming.<br>
<br>
4) We have not even begun to treat the relations of =
something
like this with partial specializations of class templates, friend
function template and class template resolutions (both with in class
scope definitions and non) and explicit template instantiations
(where the access specifier override behaviour can be of a pain).<br>
<br>
5) Combinatorial properties of ... and ...[N] should=
behave
analogously or the amount of exceptions to certain combinations
would lead us to far too many conflicts.<br>
<br>
6) If the proposal got presented at its current stat=
e without
resolving issues like the ones presented above, it would have
extreme difficulty to pass to a language core level.<br>
<br>
7) Parameter pack "bounds" can grant C++ template
meta-programming powers like the ones found in typed template
haskell or idris type providers using a series of rather WIDELY
UNKNOWN creative uses ofC++ template metaprogramming. It is off
topic to discuss this in here.<br>
<br>
<br>
I think that for the time being, I will expect a newer, better draft
of this proposal before commenting or replying further. I would not
like to end up writing another, long counter-proposal until this is
properly sorted out nor do I currently have the time for it (having
the motivation though may be detrimental). I do not like the fact
that Maurice's proposal is heavily "runtime" influenced.<br>
<br>
<br>
George<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------070501050405000204020208--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 29 May 2014 03:15:25 +0300
Raw View
This is a multi-part message in MIME format.
--------------030400000004070603080009
Content-Type: text/plain; charset=UTF-8; format=flowed
Think something like the fictional, crippled code for the sake of type
signature:
/* *WARNING*: Fictional code for a fictional question.*/
*template*<*template*<*typename*...>*class* Wrap_T
,*template*<*typename*...>*class*...[M] DiffWraps_T
,*typename* Arg >
std::vector<Wrap_T<Arg>> bundle(DiffWraps_T<Arg>...[M]) {
/* implementation here*/
}
On 05/27/2014 09:24 PM, Maurice Bos wrote:
> This feature should work with template template parameters as well,
> yes. If you have a good example of a use case, that would be great.
>
> 2014-05-26 11:36 GMT+02:00 George Makrydakis <irrequietus@gmail.com>:
>> This has significant consequences in enhancing the readability of complex
>> sfinae-heavy template metaprogramming by making pattern matching through tag
>> dispatching easier when it comes to function templates. It would also allow
>> for class template partial specializations to factor out sfinae uses in the
>> type parameters used in a given partial specialization through the
>> evaluation of N.
>>
>> Is there a reason why you would not be able to use template template
>> parameters as well directly (without wrapping them with a class template)
>> with this syntax? I do not see them mentioned or in the examples of your
>> current draft. They too make an important computational construct in
>> template metaprogramming.
>>
>> Overall, I think that metaprogrammers would be delighted by your proposal.
>> Also, it does not require any previous code to be altered if introduced into
>> the standard. Simple and dazzling.
>>
>>
>>
>> On May 26, 2014 11:48:59 AM EEST, Maurice Bos <m-ou.se@m-ou.se> wrote:
>>> Hi!
>>>
>>> Here's the draft for my proposal: http://random.m-ou.se/fspp.html
>>>
>>> Feedback is greatly appreciated.
>>>
>>> Thanks!
>>>
>>> -Maurice-
--
---
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/.
--------------030400000004070603080009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Think something like the fictional, crippled code for the sake of
type signature:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span><span style=3D"color:#898887;"> </span><b><span sty=
le=3D"color:#ca9219;background:#451e1a;">WARNING</span></b><span style=3D"c=
olor:#898887;">: Fictional code for a fictional question. </span><span styl=
e=3D"color:#898887;">*/</span>
<b>template</b>< <b>template</b><<b>typename</b>...> <b>class</b> =
Wrap_T
, <b>template</b><<b>typename</b>...> <b>class</b>...[M] Diff=
Wraps_T
, <b>typename</b> Arg >
std::vector<Wrap_T<Arg>> bundle(DiffWraps_T<Arg>...[M]) {
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
implementation here </span><span style=3D"color:#898887;">*/</span>
}
</pre>
<br>
<br>
<br>
<div class=3D"moz-cite-prefix">On 05/27/2014 09:24 PM, Maurice Bos
wrote:<br>
</div>
<blockquote
cite=3D"mid:CABbCQwvxOAAyEJBZfk7hvdVU6dURBW=3Dpx6MtZkPpg8iyicPPiQ@mail.gmai=
l.com"
type=3D"cite">
<pre wrap=3D"">This feature should work with template template parame=
ters as well,
yes. If you have a good example of a use case, that would be great.
2014-05-26 11:36 GMT+02:00 George Makrydakis <a class=3D"moz-txt-link-rfc23=
96E" href=3D"mailto:irrequietus@gmail.com"><irrequietus@gmail.com></a=
>:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">This has significant consequences in enhancing the r=
eadability of complex
sfinae-heavy template metaprogramming by making pattern matching through ta=
g
dispatching easier when it comes to function templates. It would also allow
for class template partial specializations to factor out sfinae uses in the
type parameters used in a given partial specialization through the
evaluation of N.
Is there a reason why you would not be able to use template template
parameters as well directly (without wrapping them with a class template)
with this syntax? I do not see them mentioned or in the examples of your
current draft. They too make an important computational construct in
template metaprogramming.
Overall, I think that metaprogrammers would be delighted by your proposal.
Also, it does not require any previous code to be altered if introduced int=
o
the standard. Simple and dazzling.
On May 26, 2014 11:48:59 AM EEST, Maurice Bos <a class=3D"moz-txt-link-rfc2=
396E" href=3D"mailto:m-ou.se@m-ou.se"><m-ou.se@m-ou.se></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
Hi!
Here's the draft for my proposal: <a class=3D"moz-txt-link-freetext" href=
=3D"http://random.m-ou.se/fspp.html">http://random.m-ou.se/fspp.html</a>
Feedback is greatly appreciated.
Thanks!
-Maurice-
</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------030400000004070603080009--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 29 May 2014 03:22:37 +0300
Raw View
On 05/29/2014 03:05 AM, George Makrydakis wrote:
> 3) There can be no ...[0] or [0] used explicitely because of the
> conflict described above. Cases like ...[1] and [1] would have
> additional problems as explained in 1). "Simply don't do it" is
> insufficient a reason if you intend to introduce things that can
> result in conflicts when certain instantiations are produced through
> variadic template manipulation as is done in C++11 and C++14 template
> meta-programming.
>
Think it as "be very, very, VERY" careful with [0] if you adopt it.
George
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 29 May 2014 08:41:19 +0800
Raw View
--Apple-Mail=_743A945C-B0B4-4BDF-AF1D-0846CC49E2D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-29, at 8:05 AM, George Makrydakis <irrequietus@gmail.com> wrote:
> Sorry for the delay.
>=20
> About certain examples already used, you have already provided and been p=
rovided a reply as to their correctness in the following quote:
Well, the outcome is that the examples did not correspond to the proposal, =
because sequences of packs are not allowed in primary class template parame=
ter lists. It's still not clear how they relate to any possible usage.
> Now to other things. As I have addressed in previous emails and Andrew To=
mazos did in one of his replies, the problems begin with this proposal beca=
use of conflicting semantics between definition/declaration and resulting i=
nstantiation. We have not been provided an answer by Maurice for that. Howe=
ver do note that his is a very, very early draft asking for comments. The m=
ajor problem is when we are trying to shoehorn a lot of unrelated things to=
parameter packs and I will just focus on this from Maurice's proposal:
>=20
> template<typename...[2] Args>
> void foo(Args... args)
>=20
>=20
> Type parameters, non type parameters and template template parameters (ev=
entually) using this syntax? I feel that although this is an exciting propo=
sal (for me), the current draft stage does not do it justice. I will presen=
t an alternative in the following segments that kind of says something abou=
t Maurice Bos' proposal but expands the notion to a level similar to what t=
he EWG should, where they take a lot of other things at heart other than sh=
orthands to certain kinds of notation. Let me also begin with saying that o=
ne can implement "fixed packs" at a template meta-programming library level=
in a variety of ways. Now, I will be using some specific terms as to what =
"packs" are if the notion should be extended to include "fixed" size. Let's=
proceed:
>=20
> 1. typename...[N] Args -> bounded pack (expand until N types or match to =
any number < N)
So far you've said (at length) that the current proposal is problematic and=
this is better, but without motivating either. Now we have a radical new e=
xtension, again without motivation.
> 2. typename [N] Args -> finite pack (expand or match to exactly N typ=
es)
> 3. typename... Args -> unbounded pack (the parameter pack in C++11, C+=
+14)
>=20
> Without malice, I disagree with the term "pack like repetition" you propo=
se because it is a limited case of a far more generic set. A conceptually s=
imple reason of why pack-like repetition is an unfortunate term can be seen=
when: typename...[N] is used:
>=20
> long, char, short <-- not a "repetition", but an expansion
> char, char, long <-- not a "repetition", but an expansion
> long, short, char <-- not a "repetition", but an expansion
If an argument list <long, char, short> matches a parameter list <typename =
....[ 3 ] t >, then
typename ...[ 3 ] t is a pack-like repetition expanding to typename, typena=
me, typename and declaring the pack t.
t ... is an ordinary pack expansion expanding to long, char, short. The new=
syntax was not used. There's no reason to identify use of an ordinary pack=
declared with the extension, with the extension.
> ...
> char,char,char <--- repetition of a single type, still an expansion of =
a pack
> long,long,long <--- repetition of a single type, still an expansion of =
a pack
>=20
> Therefore: typename...[N] includes both repetitive and non-repetitive exp=
ansion
The new syntax ...[ N ] does not have any non-repetitive expansions in the =
proposal. You have not provided an example. There seems to be confusion bet=
ween "expansion" of the declaration and expansion of the declared pack.
> and you cannot get around the repercussions no matter what you do. Take n=
otice now of the following scenario where multidimensionality is assumed (t=
his is not in Maurice's proposal, I am considering it for theoretical and d=
emonstrative purposes):
Why? How does this correspond to existing usage?
> When the pack is: int,char,long:
>=20
> typename...[3] Args -> int,char,long
> typename...[3][2] Args -> int,char,long,int,char,long,int,char,long
>=20
> The effect is numerically equal to N*M, meaning typename...[6] but you ha=
ve the repetition of a type PATTERN.
Are you saying that an argument list <int, char, long> matches a parameter =
list <typename ...[3][2] Args> and then the expansion Args... produces int,=
char, long, int, char, long?
This is bizarre, and it's a strawman. You need to go one step at a time.
I'm stopping here.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_743A945C-B0B4-4BDF-AF1D-0846CC49E2D3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–29, at 8:05 AM, George Makrydakis <<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
Sorry for the delay.<br>
<br>
About certain examples already used, you have already provided and
been provided a reply as to their correctness in the following
quote:<br></div></blockquote><div><br></div><div>Well, the outcome is t=
hat the examples did not correspond to the proposal, because sequences of p=
acks are not allowed in primary class template parameter lists. It’s =
still not clear how they relate to any possible usage.</div><br><blockquote=
type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">Now to other thing=
s. As I have addressed in previous emails and
Andrew Tomazos did in one of his replies, the problems begin with
this proposal because of conflicting semantics between
definition/declaration and resulting instantiation. We have not been
provided an answer by Maurice for that. However do note that his is
a very, very early draft asking for comments. The <b>major problem</b>
is when we are trying to shoehorn a lot of unrelated things to
parameter packs and I will just focus on this from Maurice's
proposal:<br>
<br>
<code><b>template</b><<b>typename</b>...[2] Args><br>
void foo(Args... args)</code><br>
<br>
<br>
Type parameters, non type parameters and template template
parameters (eventually) using this syntax? I feel that although this
is an exciting proposal (for me), the current draft stage does not
do it justice. I will present an alternative in the following
segments that kind of says something about Maurice Bos' proposal but
expands the notion to a level similar to what the EWG should, where
they take a lot of other things at heart other than shorthands to
certain kinds of notation. Let me also begin with saying that one <b>ca=
n
implement "fixed packs" at a template meta-programming library
level in a variety of ways.</b> Now, I will be using some specific
terms as to what "packs" are if the notion should be extended to
include "fixed" size. Let's proceed:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 2=
55); position: static; z-index: auto;"><span style=3D"color:#b08000;">1.</s=
pan> <b>typename</b>...[N] Args -> bounded pack (expand until N types or=
match to any number < N)
</pre></div></blockquote><div><br></div><div>So far you’ve said (at l=
ength) that the current proposal is problematic and this is better, but wit=
hout motivating either. Now we have a radical new extension, again without =
motivation.</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcolo=
r=3D"#FFFFFF"><pre style=3D"color: rgb(31, 28, 27); background-color: rgb(2=
55, 255, 255); position: static; z-index: auto;"><span style=3D"color:#b080=
00;">2.</span> <b>typename</b> [N] Args -> finite pack (expand or ma=
tch to exactly N types)
<span style=3D"color:#b08000;">3.</span> <b>typename</b>... Args -> u=
nbounded pack (the parameter pack in C++<span style=3D"color:#b08000;">11</=
span>, C++<span style=3D"color:#b08000;">14</span>)
</pre>
Without malice, I disagree with the term "pack like repetition" you
propose because it is a limited case of a far more generic set. A
conceptually simple reason of why pack-like repetition is an
unfortunate term can be seen when: <b>typename...[N]</b> is used:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 2=
55); position: static; z-index: auto;"><span style=3D"color:#0057ae;"> lon=
g</span>, <span style=3D"color:#0057ae;">char</span>, <span style=3D"color:=
#0057ae;">short</span> <-- <b>not</b> a <span style=3D"color:#bf0303;">"=
repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">char</span>, <span style=3D"color:#0057ae;=
">char</span>, <span style=3D"color:#0057ae;">long</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">long</span>, <span style=3D"color:#0057ae;=
">short</span>, <span style=3D"color:#0057ae;">char</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
</pre></div></blockquote><div><br></div><div>If an argument list <font=
face=3D"Courier"><long, char, short></font> matches a parameter list=
<font face=3D"Courier"><typename ...[ 3 ] t ></font>, then</div><div=
><br></div><div><ul class=3D"MailOutline"><li><font face=3D"Courier">typena=
me ...[ 3 ] t</font> is a pack-like repetition expanding to <font face=3D"C=
ourier">typename, typename, typename</font> and declaring the pack <font fa=
ce=3D"Courier">t</font>.</li><li><font face=3D"Courier">t ...</font> i=
s an ordinary pack expansion expanding to <font face=3D"Courier">long, char=
, short</font>. The new syntax was not used. There’s no reason to ide=
ntify <i>use</i> of an ordinary pack declared with the extension, with the =
extension.</li></ul></div><br><blockquote type=3D"cite"><div text=3D"#00000=
0" bgcolor=3D"#FFFFFF"><pre style=3D"color: rgb(31, 28, 27); background-col=
or: rgb(255, 255, 255); position: static; z-index: auto;"> ...
<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae;"=
>char</span>,<span style=3D"color:#0057ae;">char</span> <--- repetition =
of a single type, still an expansion of a pack
<span style=3D"color:#0057ae;">long</span>,<span style=3D"color:#0057ae;"=
>long</span>,<span style=3D"color:#0057ae;">long</span> <--- repetition =
of a single type, still an expansion of a pack</pre>
<br>
Therefore: <b>typename...[N]</b> includes both repetitive and
non-repetitive expansion</div></blockquote><div><br></div><div>The new =
syntax <font face=3D"Courier">...[ N ]</font> does not have any non-re=
petitive expansions in the proposal. You have not provided an example. Ther=
e seems to be confusion between “expansion” of the declaration =
and expansion of the declared pack.</div><br><blockquote type=3D"cite"><div=
text=3D"#000000" bgcolor=3D"#FFFFFF"> and you cannot get around the reperc=
ussions
no matter what you do. Take notice now of the following scenario
where multidimensionality is assumed (this is not in Maurice's
proposal, I am considering it for theoretical and demonstrative
purposes):<br></div></blockquote><div><br></div><div>Why? How does this=
correspond to existing usage?</div><br><blockquote type=3D"cite"><div text=
=3D"#000000" bgcolor=3D"#FFFFFF">When the pack is: int,char,long:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255, 255, 2=
55); position: static; z-index: auto;"><b>typename</b>...[<span style=3D"co=
lor:#b08000;">3</span>] Args -> <span style=3D"color:#0057ae;">int</s=
pan>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057a=
e;">long</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"col=
or:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</span>,<span s=
tyle=3D"color:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</spa=
n>,<span style=3D"color:#0057ae;">long</span></pre>
<br>
The effect is numerically equal to N*M, meaning typename...[6] but
you have the repetition of a <b>type PATTERN</b>.</div></blockquote><di=
v><br></div><div>Are you saying that an argument list <font face=3D"Courier=
"><int, char, long></font> matches a parameter list <font f=
ace=3D"Courier"><typename ...[3][2] Args></font> and then the ex=
pansion <font face=3D"Courier">Args...</font> produces <span styl=
e=3D"font-family: Courier;">int, char, long, </span><span style=3D"fon=
t-family: Courier;">int, char, long</span>?</div><div><br></div><div>This i=
s bizarre, and it’s a strawman. You need to go one step at a time.</d=
iv><div><br></div><div>I’m stopping here.</div><div><br></div></div><=
/body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_743A945C-B0B4-4BDF-AF1D-0846CC49E2D3--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 29 May 2014 10:47:17 +0300
Raw View
This is a multi-part message in MIME format.
--------------000303000707000302000804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05/29/2014 03:41 AM, David Krauss wrote:
>
> On 2014-05-29, at 8:05 AM, George Makrydakis <irrequietus@gmail.com
> <mailto:irrequietus@gmail.com>> wrote:
>
>> Sorry for the delay.
>>
>> About certain examples already used, you have already provided and
>> been provided a reply as to their correctness in the following quote:
>
> Well, the outcome is that the examples did not correspond to the
> proposal, because sequences of packs are not allowed in primary class
> template parameter lists. It's still not clear how they relate to any
> possible usage.
>
You are in haste, again. The Bos proposal so far *does have function
templates*. *Multiple parameter packs are allowed in function templates
in the current standard.* _*My examples focus on function templates so
far.*_ Going further down on partial class template specializations
right now would require a dedicate thread but it would touch similar
problems anyway. An example compiling perfectly with C++11, C++14:
/*
**NOTE*: Multiple parameter packs are allowed in the C++11 and C++14 standards.
* This is why this code compiles with either -std=c++11, -std=c++14 and
* of course -pedantic
*/
*#include*<cstdio>
*template*<*typename*...>
*struct* Wrap {};
*struct* Alpha {};
*struct* Beta {};
*template*<*typename*... A,*typename*... B,*template*<*typename*...>*class* I>
void function(I<A...>,I<B...>) {
printf("multiple parameter packs are allowed in the standard.\n");
}
int main() {
function(Wrap<Alpha,Beta,Beta>(), Wrap<Beta,Alpha,Beta>());
*return* {};
}
Maurice's proposal should cover cases like that for his ...[N] operator,
just because ... covers them. I will quote him from his current draft:
" So, |void foo(int...[3] args)| would make |args| a pack of three
integers, such that |foo| can be called as |foo(1,2,3)|. *Similarly,
**|template<typename...[2] Args> void foo(Args... args)|**would make
**|Args|**a pack of two typenames* (and therefore |args| a pack of two
objects of those two types)."
Also, you have been provided an answer by Ville Voutilainen as well as
correcting yourself about multiple parameter packs. The example I
offered above speaks for itself.
>>
>> Type parameters, non type parameters and template template parameters
>> (eventually) using this syntax? I feel that although this is an
>> exciting proposal (for me), the current draft stage does not do it
>> justice. I will present an alternative in the following segments that
>> kind of says something about Maurice Bos' proposal but expands the
>> notion to a level similar to what the EWG should, where they take a
>> lot of other things at heart other than shorthands to certain kinds
>> of notation. Let me also begin with saying that one *can implement
>> "fixed packs" at a template meta-programming library level in a
>> variety of ways.* Now, I will be using some specific terms as to what
>> "packs" are if the notion should be extended to include "fixed" size.
>> Let's proceed:
>>
>> 1. *typename*...[N] Args -> bounded pack (expand until N types or match to any number < N)
>
> So far you've said (at length) that the current proposal is
> problematic and this is better, but without motivating either. Now we
> have a radical new extension, again without motivation.
>
Introducing an operator that would give privileged status to one kind of
parameter (type parameters for example) over others (non-type parameters
and template template type parameters) would introduce an asymmetry that
would require us to introduce several other rules in order to avoid
conflicts as we already are noticing with Maurice's draft proposal. We
have a radically new theoretical problem, with sufficient motivation to
discuss about it. Moving on now.
>> Without malice, I disagree with the term "pack like repetition" you
>> propose because it is a limited case of a far more generic set. A
>> conceptually simple reason of why pack-like repetition is an
>> unfortunate term can be seen when: *typename...[N]* is used:
>>
>> long,char,short <--*not* a"repetition", but an expansion
>> char,char,long <--*not* a"repetition", but an expansion
>> long,short,char <--*not* a"repetition", but an expansion
> The new syntax ...[ N ] does not have any non-repetitive expansions in
> the proposal. You have not provided an example. There seems to be
> confusion between "expansion" of the declaration and expansion of the
> declared pack.
I am taking this straight out of Maurice Bos' current draft for what
concerns the validity of the claim that this would lead to
non-repetitive expansions. Again:
" So, |void foo(int...[3] args)| would make |args| a pack of three
integers, such that |foo| can be called as |foo(1,2,3)|. *Similarly,
**|template<typename...[2] Args> void foo(Args... args)|**would make
**|Args|**a pack of two typenames* (and therefore |args| a pack of two
objects of those two types)."
In other words, *typename... [N] is not int ...[N]. *An expansion of a
type parameter pack does not always result into an instantiation where
the same type is repeated N times unless you are referring to a non-type
parameter pack.
Do you really not see the difference between type parameter expansion
and non-type parameter one? If what he wants - and you of course - is
repetition, that is what a typename... [3][2] would do for a type
parameter pack of 3, by repeating it 2 times. Only that this would be a
*type pattern repetition*, not a *type repetition*.
>
>> and you cannot get around the repercussions no matter what you do.
>> Take notice now of the following scenario where multidimensionality
>> is assumed (this is not in Maurice's proposal, I am considering it
>> for theoretical and demonstrative purposes):
>
> Why? How does this correspond to existing usage?
Repetition and expansion are two different concepts. In order to make
sure that you force repetition explicitly for a "fixed size" (as is the
author's original intent)*including both a single type **and**a sequence
of types*, you would need the multidimensional notation.
>
>> When the pack is: int,char,long:
>>
>> *typename*...[3] Args ->int,char,long
>> *typename*...[3][2] Args ->int,char,long,int,char,long,int,char,long
>>
>> The effect is numerically equal to N*M, meaning typename...[6] but
>> you have the repetition of a *type PATTERN*.
>
> Are you saying that an argument list <int, char, long> matches a
> parameter list <typename ...[3][2] Args> and then the expansion
> Args... produces int, char, long, int, char, long?
>
This is clear enough in the example *already given* in my previous
email, if you haven't noticed and there is an explanation for that (see
multidimensionality, which is not proposed and has type pattern
repetition effects):
*typename*...[3] Args ->int,char,long
*typename*...[3][2] Args ->int,char,long,int,char,long,int,char,long
> This is bizarre, and it's a strawman. You need to go one step at a time.
>
> I'm stopping here.
>
No hard feelings, though it does not apply.
Discussing about the consequences of a proposal draft is *not* an
informal fallacy based on misrepresentation of the original problem
(straw man), when the current formulation of the problem and proposed
solution by the OP is itself incomplete and offering itself for scrutiny
by default.
Introducing another pack expansion notation in declaration/definition
without dealing with template instantiation conflicts is a major point
of incoherence. The purpose of my analysis is to extend both the
formulation of the original problem and provide a more all-encompassing
solution. Need it be, a separate counter-proposal will be formulated but
not now.
Generalizing handy run-time shorthands to what happens during template
instantiation (function templates, partial specializations, multiple
parameter packs wherever applicable) and hastily treating non-type and
type parameter expansion, is bordering on a form of an inductive
informal fallacy called *association fallacy*. See first-order logic.
George
--
---
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/.
--------------000303000707000302000804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<div class=3D"moz-cite-prefix">On 05/29/2014 03:41 AM, David Krauss
wrote:<br>
</div>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Dwindows-1252">
<br>
<div>
<div>On 2014–05–29, at 8:05 AM, George Makrydakis <<=
a
moz-do-not-send=3D"true" href=3D"mailto:irrequietus@gmail.com">=
irrequietus@gmail.com</a>>
wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> Sorry for the delay.<b=
r>
<br>
About certain examples already used, you have already
provided and been provided a reply as to their correctness
in the following quote:<br>
</div>
</blockquote>
<div><br>
</div>
<div>Well, the outcome is that the examples did not correspond
to the proposal, because sequences of packs are not allowed in
primary class template parameter lists. It’s still not clea=
r
how they relate to any possible usage.</div>
<br>
</div>
</blockquote>
<br>
You are in haste, again. The Bos proposal so far <b>does have
function templates</b>. <b>Multiple parameter packs are allowed
in function templates in the current standard.</b> <font
color=3D"#cc0000"><u><b>My examples focus on function templates so
far.</b></u></font> Going further down on partial class
template specializations right now would require a dedicate thread
but it would touch similar problems anyway. An example compiling
perfectly with C++11, C++14:<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">/*</span>
<span style=3D"color:#898887;"> * </span><b><span style=3D"color:#81ca2d;ba=
ckground:#f7e6e6;">NOTE</span></b><span style=3D"color:#898887;">: Multiple=
parameter packs are allowed in the C++11 and C++14 standards.</span>
<span style=3D"color:#898887;"> * This is why this code compiles with=
either -std=3Dc++11, -std=3Dc++14 and</span>
<span style=3D"color:#898887;"> * of course -pedantic</span>
<span style=3D"color:#898887;"> </span><span style=3D"color:#898887;">*/</s=
pan>
<b><span style=3D"color:#278cc9;">#include </span></b><span style=3D"color:=
#278cc9;"><cstdio></span>
<b>template</b><<b>typename</b>...>
<b>struct</b> Wrap {};
<b>struct</b> Alpha {};
<b>struct</b> Beta {};
<b>template</b><<b>typename</b>... A, <b>typename</b>... B, <b>template<=
/b><<b>typename</b>...> <b>class</b> I>
<span style=3D"color:#0057ae;">void</span> function(I<A...>,I<B...=
>) {
printf(<span style=3D"color:#bf0303;">"multiple parameter packs are all=
owed in the standard.</span><span style=3D"color:#924c9d;">\n</span><span s=
tyle=3D"color:#bf0303;">"</span>);
}
<span style=3D"color:#0057ae;">int</span> main() {
function(Wrap<Alpha,Beta,Beta>(), Wrap<Beta,Alpha,Beta>());
<b>return</b> {};
}</pre>
<br>
<br>
Maurice's proposal should cover cases like that for his ...[N]
operator, just because ... covers them. I will quote him from his
current draft:<br>
<br>
" So, <code>void foo(int...[3] args)</code> would make <code>args</code=
>
a pack of three integers, such that <code>foo</code> can be called
as <code>foo(1,2,3)</code>. <b>Similarly, </b><b><code>template<type=
name...[2]
Args> void foo(Args... args)</code></b><b> would make </b><b><co=
de>Args</code></b><b>
a pack of two typenames</b> (and therefore <code>args</code> a
pack of two objects of those two types)."<br>
<br>
Also, you have been provided an answer by Ville Voutilainen as well
as correcting yourself about multiple parameter packs. The example I
offered above speaks for itself.<br>
<br>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><br>
Type parameters, non type parameters and template template
parameters (eventually) using this syntax? I feel that
although this is an exciting proposal (for me), the current
draft stage does not do it justice. I will present an
alternative in the following segments that kind of says
something about Maurice Bos' proposal but expands the notion
to a level similar to what the EWG should, where they take a
lot of other things at heart other than shorthands to
certain kinds of notation. Let me also begin with saying
that one <b>can implement "fixed packs" at a template
meta-programming library level in a variety of ways.</b>
Now, I will be using some specific terms as to what "packs"
are if the notion should be extended to include "fixed"
size. Let's proceed:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255=
, 255, 255); position: static; z-index: auto;"><span style=3D"color:#b08000=
;">1.</span> <b>typename</b>...[N] Args -> bounded pack (expand until N =
types or match to any number < N)
</pre>
</div>
</blockquote>
<div><br>
</div>
<div>So far you’ve said (at length) that the current proposal=
is
problematic and this is better, but without motivating either.
Now we have a radical new extension, again without motivation.</d=
iv>
<br>
</div>
</blockquote>
Introducing an operator that would give privileged status to one
kind of parameter (type parameters for example) over others
(non-type parameters and template template type parameters) would
introduce an asymmetry that would require us to introduce several
other rules in order to avoid conflicts as we already are noticing
with Maurice's draft proposal. We have a radically new theoretical
problem, with sufficient motivation to discuss about it. Moving on
now.<br>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> Without malice, I
disagree with the term "pack like repetition" you propose
because it is a limited case of a far more generic set. A
conceptually simple reason of why pack-like repetition is an
unfortunate term can be seen when: <b>typename...[N]</b> is
used:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255=
, 255, 255); position: static; z-index: auto;"><span style=3D"color:#0057ae=
;"> long</span>, <span style=3D"color:#0057ae;">char</span>, <span style=
=3D"color:#0057ae;">short</span> <-- <b>not</b> a <span style=3D"color:#=
bf0303;">"repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">char</span>, <span style=3D"color:#0057ae;=
">char</span>, <span style=3D"color:#0057ae;">long</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
<span style=3D"color:#0057ae;">long</span>, <span style=3D"color:#0057ae;=
">short</span>, <span style=3D"color:#0057ae;">char</span> <-- <b>not</b=
> a <span style=3D"color:#bf0303;">"repetition"</span>, but an expansion
</pre>
</div>
</blockquote>
<div>The new syntax <font face=3D"Courier">...[ N ]</font> doe=
s
not have any non-repetitive expansions in the proposal. You
have not provided an example. There seems to be confusion
between “expansion” of the declaration and expansion =
of the
declared pack.</div>
</div>
</blockquote>
<br>
I am taking this straight out of Maurice Bos' current draft for what
concerns the validity of the claim that this would lead to
non-repetitive expansions. Again:<br>
<br>
" So, <code>void foo(int...[3] args)</code> would make <code>args</code=
>
a pack of three integers, such that <code>foo</code> can be called
as <code>foo(1,2,3)</code>. <b>Similarly, </b><b><code>template<type=
name...[2]
Args> void foo(Args... args)</code></b><b> would make </b><b><co=
de>Args</code></b><b>
a pack of two typenames</b> (and therefore <code>args</code> a
pack of two objects of those two types)."<br>
<br>
In other words, <b>typename... [N] is not int ...[N]. </b>An
expansion of a type parameter pack does not always result into an
instantiation where the same type is repeated N times unless you are
referring to a non-type parameter pack.<br>
<br>
Do you really not see the difference between type parameter
expansion and non-type parameter one? If what he wants - and you of
course - is repetition, that is what a typename... [3][2] would do
for a type parameter pack of 3, by repeating it 2 times. Only that
this would be a <b>type pattern repetition</b>, not a <b>type
repetition</b>.<br>
<br>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<div><br>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF"> and you cannot get
around the repercussions no matter what you do. Take notice
now of the following scenario where multidimensionality is
assumed (this is not in Maurice's proposal, I am considering
it for theoretical and demonstrative purposes):<br>
</div>
</blockquote>
<div><br>
</div>
<div>Why? How does this correspond to existing usage?</div>
</div>
</blockquote>
Repetition and expansion are two different concepts. In order to
make sure that you force repetition explicitly for a "fixed size"
(as is the author's original intent)<b> including both a single type
</b><b>and</b><b> a sequence of types</b>, you would need the
multidimensional notation.<br>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<div><br>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">When the pack is:
int,char,long:<br>
<br>
<pre style=3D"color: rgb(31, 28, 27); background-color: rgb(255=
, 255, 255); position: static; z-index: auto;"><b>typename</b>...[<span sty=
le=3D"color:#b08000;">3</span>] Args -> <span style=3D"color:#0057ae;=
">int</span>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"colo=
r:#0057ae;">long</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"col=
or:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</span>,<span s=
tyle=3D"color:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</spa=
n>,<span style=3D"color:#0057ae;">long</span></pre>
<br>
The effect is numerically equal to N*M, meaning
typename...[6] but you have the repetition of a <b>type
PATTERN</b>.</div>
</blockquote>
<div><br>
</div>
<div>Are you saying that an argument list <font face=3D"Courier">&l=
t;int,
char, long></font> matches a parameter list <font
face=3D"Courier"><typename ...[3][2] Args></font> an=
d
then the expansion <font face=3D"Courier">Args...</font> pro=
duces <span
style=3D"font-family: Courier;">int, char, long, </span><s=
pan
style=3D"font-family: Courier;">int, char, long</span>?</div>
<div><br>
</div>
</div>
</blockquote>
This is clear enough in the example <b>already given</b> in my
previous email, if you haven't noticed and there is an explanation
for that (see multidimensionality, which is not proposed and has
type pattern repetition effects):<br>
<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>typename</b>.=
...[<span style=3D"color:#b08000;">3</span>] Args -> <span style=3D"co=
lor:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</span>,<span s=
tyle=3D"color:#0057ae;">long</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>,<span style=3D"color:#0057ae;">int</span>,<span style=3D"col=
or:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</span>,<span s=
tyle=3D"color:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</spa=
n>,<span style=3D"color:#0057ae;">long</span></pre>
<br>
<blockquote
cite=3D"mid:D765A496-2432-4A5E-B565-CF23E2B2B410@gmail.com"
type=3D"cite">
<div>
<div>This is bizarre, and it’s a strawman. You need to go one
step at a time.</div>
<div><br>
</div>
<div>I’m stopping here.</div>
<div><br>
</div>
</div>
</blockquote>
No hard feelings, though it does not apply.<br>
<br>
Discussing about the consequences of a proposal draft is <b>not</b>
an informal fallacy based on misrepresentation of the original
problem (straw man), when the current formulation of the problem and
proposed solution by the OP is itself incomplete and offering itself
for scrutiny by default.<br>
<br>
Introducing another pack expansion notation in
declaration/definition without dealing with template instantiation
conflicts is a major point of incoherence. The purpose of my
analysis is to extend both the formulation of the original problem
and provide a more all-encompassing solution. Need it be, a separate
counter-proposal will be formulated but not now.<br>
<br>
Generalizing handy run-time shorthands to what happens during
template instantiation (function templates, partial specializations,
multiple parameter packs wherever applicable) and hastily treating
non-type and type parameter expansion, is bordering on a form of an
inductive informal fallacy called <b>association fallacy</b>. See
first-order logic.<br>
<br>
George<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------000303000707000302000804--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 29 May 2014 04:14:28 -0700 (PDT)
Raw View
------=_Part_3191_32387566.1401362068271
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, 29 May 2014 08:47:36 UTC+1, George Makrydakis wrote:=20
>
> *typename*...[3][2] Args -> int,char,long,int,char,long,int,char,long
>
> I don=E2=80=99t get this=E2=80=94I count *nine* types in the expansion, n=
ot six (3 =C3=97 2). =20
Am I missing something?
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3191_32387566.1401362068271
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><BR>On Thursday, 29 May 2014 08:47:36 UTC+1, George Makryd=
akis wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV bgcolor=3D"#FFFFFF" text=3D"#000000">
<BLOCKQUOTE type=3D"cite">
<DIV>
<BLOCKQUOTE type=3D"cite">
<DIV bgcolor=3D"#FFFFFF" text=3D"#000000"><PRE style=3D"BACKGROUND-COLOR: r=
gb(255,255,255); COLOR: rgb(31,28,27)"><B>typename</B>...[<SPAN style=3D"CO=
LOR: #b08000">3</SPAN>][<SPAN style=3D"COLOR: #b08000">2</SPAN>] Args ->=
<SPAN style=3D"COLOR: #0057ae">int</SPAN>,<SPAN style=3D"COLOR: #0057ae">c=
har</SPAN>,<SPAN style=3D"COLOR: #0057ae">long</SPAN>,<SPAN style=3D"COLOR:=
#0057ae">int</SPAN>,<SPAN style=3D"COLOR: #0057ae">char</SPAN>,<SPAN style=
=3D"COLOR: #0057ae">long</SPAN>,<SPAN style=3D"COLOR: #0057ae">in<WBR>t</SP=
AN>,<SPAN style=3D"COLOR: #0057ae">char</SPAN>,<SPAN style=3D"COLOR: #0057a=
e">long</SPAN></PRE></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></DIV></BLOCKQUOT=
E>
<DIV>I don=E2=80=99t get this=E2=80=94I count <EM>nine</EM> types in the ex=
pansion, not six (3 =C3=97 2). Am I missing something?</DIV></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3191_32387566.1401362068271--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 29 May 2014 16:54:04 +0300
Raw View
This is a multi-part message in MIME format.
--------------060408070602060505060904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Correct, this is an obvious editing error.
Here is the notion as is intended:
*typename*...[3] Args ->int,char,long /* default, up to 3 types*/
*typename*...[3][1] Args ->int,char,long /* int,char,long x 1*/
*typename*...[3][2] Args ->int,char,long
,int,char,long /* int,char,long x 2*/
=20
*typename*...[3][3] Args ->int,char,long
,int,char,long
,int,char,long /* int,char,long x 3*/
/* .... and so on*/
Thank you very much.
George
On 05/29/2014 02:14 PM, Douglas Boffey wrote:
>
> On Thursday, 29 May 2014 08:47:36 UTC+1, George Makrydakis wrote:
>
>>> *typename*...[3][2] Args ->int,char,long,int,char,long,int,char,lon=
g
>
> I don=E2=80=99t get this=E2=80=94I count /nine/ types in the expansion, n=
ot six (3 =C3=97=20
> 2). Am I missing something?
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------060408070602060505060904
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Correct, this is an obvious editing error.<br>
<br>
Here is the notion as is intended:<br>
<pre style=3D"color:#1f1c1b;background-color:#ffffff;"><b>typename</b>.=
...[<span style=3D"color:#b08000;">3</span>] Args -> <span style=3D"co=
lor:#0057ae;">int</span>,<span style=3D"color:#0057ae;">char</span>,<span s=
tyle=3D"color:#0057ae;">long</span> <span style=3D"color:#898887;">/*</span=
><span style=3D"color:#898887;"> default, up to 3 types </span><span style=
=3D"color:#898887;">*/</span>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">1</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span> <span style=3D"color:#898887;">/*</span><span style=3D"color=
:#898887;"> int,char,long x 1 </span><span style=3D"color:#898887;">*/</spa=
n>
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">2</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>
, <span style=3D"color:#0057ae;">int</span>,<span s=
tyle=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</sp=
an> <span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
int,char,long x 2 </span><span style=3D"color:#898887;">*/</span>
=20
<b>typename</b>...[<span style=3D"color:#b08000;">3</span>][<span style=3D"=
color:#b08000;">3</span>] Args -> <span style=3D"color:#0057ae;">int</sp=
an>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae=
;">long</span>
, <span style=3D"color:#0057ae;">int</span>,<span s=
tyle=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</sp=
an>
, <span style=3D"color:#0057ae;">int</span>,<span s=
tyle=3D"color:#0057ae;">char</span>,<span style=3D"color:#0057ae;">long</sp=
an> <span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;">=
int,char,long x 3 </span><span style=3D"color:#898887;">*/</span>
<span style=3D"color:#898887;">/*</span><span style=3D"color:#898887;"> ...=
.. and so on </span><span style=3D"color:#898887;">*/</span></pre>
<br>
Thank you very much.<br>
<br>
George<br>
<br>
<div class=3D"moz-cite-prefix">On 05/29/2014 02:14 PM, Douglas Boffey
wrote:<br>
</div>
<blockquote
cite=3D"mid:3f0e6f21-eb47-4d36-a1d8-da6232fc88e3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
On Thursday, 29 May 2014 08:47:36 UTC+1, George Makrydakis
wrote:
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px
0px 0.8ex; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote type=3D"cite">
<div>
<blockquote type=3D"cite">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<pre style=3D"BACKGROUND-COLOR: rgb(255,255,255); COLOR=
: rgb(31,28,27)"><b>typename</b>...[<span style=3D"COLOR: #b08000">3</span>=
][<span style=3D"COLOR: #b08000">2</span>] Args -> <span style=3D"COLOR:=
#0057ae">int</span>,<span style=3D"COLOR: #0057ae">char</span>,<span style=
=3D"COLOR: #0057ae">long</span>,<span style=3D"COLOR: #0057ae">int</span>,<=
span style=3D"COLOR: #0057ae">char</span>,<span style=3D"COLOR: #0057ae">lo=
ng</span>,<span style=3D"COLOR: #0057ae">in<wbr>t</span>,<span style=3D"COL=
OR: #0057ae">char</span>,<span style=3D"COLOR: #0057ae">long</span></pre>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<div>I don=E2=80=99t get this=E2=80=94I count <em>nine</em> types i=
n the
expansion, not six (3 =C3=97 2).=C2=A0 Am I missing something?</d=
iv>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------060408070602060505060904--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Fri, 30 May 2014 02:33:25 +0300
Raw View
--001a113abec801ec9304fa925b5f
Content-Type: text/plain; charset=UTF-8
After discussing this with Maurice, I concluded that he will just be
proposing shorthand notation, even after certain ambiguities lacking
explanation in his current draft are properly addressed. However, I do
believe that extending pack semantics properly to the point of providing
"pack manipulation" - without introducing backwards-breaking changes - is a
better approach to solving a wider series of code generation problems.
"Fixed size parameter packs" are just one of the simpler cases where such
an approach could be beneficial. I will explore what extending pack
notation means for pack expansions further and produce a separate document
at some non distant point if it continues to peak my own interest.
Good luck with your own proposal Maurice,
George
--
---
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/.
--001a113abec801ec9304fa925b5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>After discussing this with Maurice, I concluded that<=
b> </b>he will just be proposing shorthand notation, even after certain amb=
iguities lacking explanation in his current draft are properly addressed. H=
owever, I do believe that extending pack semantics properly to the point of=
providing "pack manipulation" - without introducing backwards-br=
eaking changes<b> </b>- is a better approach to solving a wider series of c=
ode generation problems. "Fixed size parameter packs" are just on=
e of the simpler cases where such an approach could be beneficial. I will e=
xplore what extending pack notation means for pack expansions further and p=
roduce a separate document at some non distant point if it continues to pea=
k my own interest.<br>
<br></div><div>Good luck with your own proposal Maurice,<br><br></div><div>=
George<br></div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113abec801ec9304fa925b5f--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 30 May 2014 09:47:56 +0200
Raw View
On Thu, May 29, 2014 at 03:15:25AM +0300, George Makrydakis wrote:
> Think something like the fictional, crippled code for the sake of type
> signature:
>
> /* *WARNING*: Fictional code for a fictional question.*/
> *template*<*template*<*typename*...>*class* Wrap_T
> ,*template*<*typename*...>*class*...[M] DiffWraps_T
> ,*typename* Arg >
> std::vector<Wrap_T<Arg>> bundle(DiffWraps_T<Arg>...[M]) {
> /* implementation here*/
> }
Could you please refrain from using <strong> in your examples since it makes
it hard to see the proposal due to all the *'s your mailer adds.
/MF
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Fri, 30 May 2014 10:51:43 +0300
Raw View
I will see to changing my default syntax highlighter rendering in HTML.
Thanks for your comment,
George
On 05/30/2014 10:47 AM, Magnus Fromreide wrote:
> On Thu, May 29, 2014 at 03:15:25AM +0300, George Makrydakis wrote:
>> Think something like the fictional, crippled code for the sake of type
>> signature:
>>
>> /* *WARNING*: Fictional code for a fictional question.*/
>> *template*<*template*<*typename*...>*class* Wrap_T
>> ,*template*<*typename*...>*class*...[M] DiffWraps_T
>> ,*typename* Arg >
>> std::vector<Wrap_T<Arg>> bundle(DiffWraps_T<Arg>...[M]) {
>> /* implementation here*/
>> }
> Could you please refrain from using <strong> in your examples since it makes
> it hard to see the proposal due to all the *'s your mailer adds.
>
> /MF
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Sun, 15 Jun 2014 21:36:20 +0300
Raw View
This is a multi-part message in MIME format.
--------------060402060206030701040604
Content-Type: text/plain; charset=UTF-8; format=flowed
On 05/30/2014 02:33 AM, George Makrydakis wrote:
> After discussing this with Maurice, I concluded that**he will just be
> proposing shorthand notation, even after certain ambiguities lacking
> explanation in his current draft are properly addressed. However, I do
> believe that extending pack semantics properly to the point of
> providing "pack manipulation" - without introducing backwards-breaking
> changes**- is a better approach to solving a wider series of code
> generation problems. "Fixed size parameter packs" are just one of the
> simpler cases where such an approach could be beneficial. I will
> explore what extending pack notation means for pack expansions further
> and produce a separate document at some non distant point if it
> continues to peak my own interest.
>
> Good luck with your own proposal Maurice,
>
> George
>
After working on this, my Initial draft is up: here
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7WdwA/oOX1NzI43YsJ>
Thanks,
George
--
---
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/.
--------------060402060206030701040604
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 05/30/2014 02:33 AM, George
Makrydakis wrote:<br>
</div>
<blockquote
cite="mid:CAPkOUViZ8bM3KR_JoAdteQdwLF5cGrgKAqzpwmS_ykU-mwEdSQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>After discussing this with Maurice, I concluded that<b> </b>he
will just be proposing shorthand notation, even after certain
ambiguities lacking explanation in his current draft are
properly addressed. However, I do believe that extending pack
semantics properly to the point of providing "pack
manipulation" - without introducing backwards-breaking changes<b>
</b>- is a better approach to solving a wider series of code
generation problems. "Fixed size parameter packs" are just one
of the simpler cases where such an approach could be
beneficial. I will explore what extending pack notation means
for pack expansions further and produce a separate document at
some non distant point if it continues to peak my own
interest.<br>
<br>
</div>
<div>Good luck with your own proposal Maurice,<br>
<br>
</div>
<div>George<br>
</div>
<div><br>
</div>
</div>
</blockquote>
After working on this, my Initial draft is up: <a
href="https://groups.google.com/a/isocpp.org/d/msg/std-proposals/qIs0Ws7WdwA/oOX1NzI43YsJ">here</a><br>
<br>
Thanks,<br>
<br>
George<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------060402060206030701040604--
.