------=_Part_4294_1009880911.1413313374244
Content-Type: text/plain; charset=UTF-8

As part of N4144, it would be incredibly useful to include the abilities to
get the index of a type in a pack (first occurance at least) and to get a
type at an index. It allows for some very powerful compile-time
transformations necessary to support a variadic container type (e.g.
boost::variadic) without requiring RTTI (which is important for a variant
to be useful to the many domains of users that use -fno-rtti or equivalent
for various reasons).

In a previous small paper I proposed type_at<>, which I meant to submit an
update to this time but got distracted with that pesky "job" thing, which
would have addressed the committee's feedback on the original proposal as
well as add a type_index_of<> template. I don't have the implementations
easily accessible at the moment, but they're both very simple sets of
templates, and as per committee feedback trigger SFINAE rather than hard
errors on any failure (if you index past the end of a parameter pack or if
you ask for the index of a type not present). If the idea is to move most
uses of type lists to the packer type in N4144 then it should provide those
operations.

Summary: please consider adding an index_of<typename T, packer<...>> that
returns a std::integral_constant<size_t, N> where N is the first "index"
into the parameter pack of the requested type, and add a
type_at<packer<...>, size_t N> that maps an index to a type at the given
index, with SFINAE failures in both cases the requested type or index is
invalid.

--

---
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_4294_1009880911.1413313374244
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><font face=3D"arial, sans-serif" size=3D"2">As part of N41=
44, it would be incredibly useful to include the abilities to get the index=
 of a type in a pack (first occurance at least) and to get a type at an ind=
ex. It allows for some very powerful compile-time transformations necessary=
 to support a variadic container type (e.g. boost::variadic) without requir=
ing RTTI (which is important for a variant to be useful to the many domains=
 of users that use -fno-rtti or equivalent for various reasons).</font><div=
><font face=3D"arial, sans-serif" size=3D"2"><br></font></div><div><font fa=
ce=3D"arial, sans-serif" size=3D"2">In a previous small paper I proposed ty=
pe_at&lt;&gt;, which I meant to submit an update to this time but got distr=
acted with that pesky "job" thing, which would have addressed the committee=
's feedback on the original proposal as well as add a type_index_of&lt;&gt;=
 template. I don't have the implementations easily accessible at the moment=
, but they're both very simple sets of templates, and as per committee feed=
back trigger SFINAE rather than hard errors on any failure (if you index pa=
st the end of a parameter pack or if you ask for the index of a type not pr=
esent). If the idea is to move most uses of type lists to the packer type i=
n N4144 then it should provide those operations.</font></div><div><font siz=
e=3D"2"><br></font></div><div><font face=3D"arial, sans-serif" size=3D"2">S=
ummary: please consider adding<span style=3D"color: rgb(0, 0, 0);">&nbsp;an=
 index_of&lt;typename T, packer&lt;...&gt;&gt; that returns a std::integral=
_constant&lt;size_t, N&gt; where N is the first "index" into the parameter =
pack of the requested type, and add a type_at&lt;packer&lt;...&gt;, size_t =
N&gt; that maps an index to a type at the given index, with SFINAE failures=
 in both cases the requested type or index is invalid.</span></font></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_4294_1009880911.1413313374244--

.

------=_Part_2124_848801996.1413369148285
Content-Type: text/plain; charset=UTF-8

It is relevant to mention the recent paper by Daveed Vandevoorde, *N4235*
that is in direct relation to EWG#30. if accepted it would render
implementation of things like std::packer easier. The direct link is at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4235.htm. Some
aspects of it have to be discussed given *N4144* enters the family of
parameter pack manipulation, in a wider context. This email is feedback for
both N4235 and N4144 and I am CC'ing it to the people directly involved.

First, I find it extremely flattering that Vandevoorde went up proposing
parts of a significantly integrated feature draft he said that it "would
complicate the language and strain the compiler" in its substance, when
annotated template parameter packs were discussed in haste. That was an
idea seeking guidance and *not* in the final form of a proposal (
http://atpp.irrequietus.eu and https://github.com/irrequietus/atpp still
ongoing), which was given a "library" recommendation without any voting
going on. I also find it quite flattering that he omits giving credit to
that work and the discussion both in session and out in his acknowledgment
list, given that no syntactical ambiguities (at present C++ standard draft
status) existed and no "lexer hacks" would have been necessary - as they
are in his paper. Voutilainen (thanks Ville) gives credit to atpp in his
update to EWG#30. In specific, Vandevoorde's "pack sub-setting" and other
features are just using alternative syntax for access/interval annotation.
Individual access was and is also part of atpp; as well as sequenced
pattern reflection, size constraints, partial ordering, patterned expansion
etc. Also, there are a lot of other things Vandevoorde does not address in
his paper in relation to such pack manipulation the way he proposes it, but
I guess *he* is allowed to omit them. Some practical examples in relation
to expansion and pack sub-setting (atpp also covers declaration):

N4144: Ts.<1 ...< sizeof...(Ts)>
ATPP : Ts{1,sizeof...(Ts)}...

N4144: Ts.[N]
ATPP: Ts{N}

N4144: Ts.<(0 ...< sizeof...(Ts)), (0 ...< sizeof...(Ts))>

ATPP: Ts{}[2]...

For the record, Vandevoorde's expansion does not cover what happens when
F<Ts>... is the intention (valid C++ construct applying F over the Ts
pack), nor the actual issue behind the addition of other expressions to
sizeof...(Ts) in relation to eventually recursive use of such construct.
ATPP does. In relation to the F<X>... construct I am referring to (which in
the end proves the haskellian fmap-like character of this valid C++ rule):

#include <cstdio>
template<typename...> struct Helper {};

template<template<typename...> class F, typename... X>
void fun(F<X>...)
{ printf("hello, world\n"); }

int main() {
    fun(Helper<int>(), Helper<long>(), Helper<char>());
    return 0;
}

It is interesting to note that Vandevoorde's approach is for generating
integer sequences for pack accessing over specifying them as range/interval
endpoints to achieve the same effect of ATPP but with increased verbosity
and parsing requirements while also introducing another construct for
integer generation.

People designing libraries for packs (like *std::packer*), should take
under consideration things like N4144 or other proposals coming about based
on prior work given that we are talking about C++17 and past that for
general use. Any extension to packs (which the multitude of experienced C++
programmers desire) does not overlap with concepts, given that pack
processing is capable of far more than providing a means for bounded
parametric polymorphism to be "worked" around into the language. Such
additions will greatly enhance the uncanny and arcanely "evil" usefulness
of templates, to the absolute horror of their creator. Think of what
happens when the output of constexpr functions is used as input for such
integral constant expression pack syntax in combination to the beloved
concepts. Packs need to be provided with a language level access interface
so that more useful constructs can be made, regardless of who is behind it.

Libraries (such as the proposed *std::packer*) using such features will be
more powerful because they will be able to systematically provide pack
manipulation at a lower instantiation (both in boilerplate and compiler
internals) cost, opening up pandora's box for twisting the language into
absurdly unnatural but highly expressive code. Therefore, certain EWG
deliberations on "library recommendations" to prior work like the one done
in atpp, are misleading, if an EWG member who was "against" them picks up
on their exact technical substance. Either way, serious template
metaprogrammers get what they want, on a programming style concretely
presented initially by Erwin Unruh long time ago. I foresee a set of
features proposed by different people, previously fearful of "complexity",
to be bundled together into forming the substance of pack annotation (atpp)
soon enough, given that all of this background interplay is finally giving
priority to an active EWG issue for more than two years. In the end, this
was not a question of technical completeness and adequacy, but a question
of leverage leading to pyrrhic victories.

I look forward to seeing the evident outcome of Vandevoorde's efforts and
be flattered more by them. I think that a library like std::packer propose
should take into serious consideration ongoing work in the EWG in order to
resolve to an implementation that takes into the account C++17 (?)
developments at the language level without wasting their time. Whether
there is std::tuple overlap (as elsewhere implied by other authors) is
irrelevant because std::tuple is "worked around" into fitting parameter
pack manipulation for the lack of boost::mpl::vector like features and is
not a first-class library feature for such things.

Thank you for your time and consideration.

George

On Tuesday, October 14, 2014 10:02:54 PM UTC+3, Sean Middleditch wrote:
>
> As part of N4144, it would be incredibly useful to include the abilities
> to get the index of a type in a pack (first occurance at least) and to get
> a type at an index. It allows for some very powerful compile-time
> transformations necessary to support a variadic container type (e.g.
> boost::variadic) without requiring RTTI (which is important for a variant
> to be useful to the many domains of users that use -fno-rtti or equivalent
> for various reasons).
>
> In a previous small paper I proposed type_at<>, which I meant to submit an
> update to this time but got distracted with that pesky "job" thing, which
> would have addressed the committee's feedback on the original proposal as
> well as add a type_index_of<> template. I don't have the implementations
> easily accessible at the moment, but they're both very simple sets of
> templates, and as per committee feedback trigger SFINAE rather than hard
> errors on any failure (if you index past the end of a parameter pack or if
> you ask for the index of a type not present). If the idea is to move most
> uses of type lists to the packer type in N4144 then it should provide those
> operations.
>
> Summary: please consider adding an index_of<typename T, packer<...>> that
> returns a std::integral_constant<size_t, N> where N is the first "index"
> into the parameter pack of the requested type, and add a
> type_at<packer<...>, size_t N> that maps an index to a type at the given
> index, with SFINAE failures in both cases the requested type or index is
> invalid.
>

--

---
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_2124_848801996.1413369148285
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is relevant to mention the recent paper by Daveed Vande=
voorde, <b>N4235</b> that is in direct relation to EWG#30. if accepted it w=
ould render implementation of things like std::packer easier. The direct li=
nk is at: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
4/n4235.htm">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4235.=
htm</a>. Some aspects of it have to be discussed given <b>N4144</b> enters =
the family of parameter pack manipulation, in a wider context. This email i=
s feedback for both N4235 and N4144 and I am CC'ing it to the people direct=
ly involved.<br><br>First, I find it extremely flattering that Vandevoorde =
went up proposing parts of a significantly integrated feature draft he said=
 that it "would complicate the language and strain the compiler" in its sub=
stance, when annotated template parameter packs were discussed in haste. Th=
at was an idea seeking guidance and <b>not</b> in the final form of a propo=
sal (<a href=3D"http://atpp.irrequietus.eu">http://atpp.irrequietus.eu</a> =
and <a href=3D"https://github.com/irrequietus/atpp">https://github.com/irre=
quietus/atpp</a> still ongoing), which was given a "library" recommendation=
 without any voting going on. I also find it quite flattering that he omits=
 giving credit to that work and the discussion both in session and out in h=
is acknowledgment list, given that no syntactical ambiguities (at present C=
++ standard draft status) existed and no "lexer hacks" would have been nece=
ssary - as they are in his paper. Voutilainen (thanks Ville) gives credit t=
o atpp in his update to EWG#30. In specific, Vandevoorde's "pack sub-settin=
g" and other features are just using alternative syntax for access/interval=
 annotation. Individual access was and is also part of atpp; as well as seq=
uenced pattern reflection, size constraints, partial ordering, patterned ex=
pansion etc. Also, there are a lot of other things Vandevoorde does not add=
ress in his paper in relation to such pack manipulation the way he proposes=
 it, but I guess <i>he</i> is allowed to omit them. Some practical examples=
 in relation to expansion and pack sub-setting (atpp also covers declaratio=
n):<br><br>N4144: Ts.&lt;1 ...&lt; sizeof...(Ts)&gt;<br>ATPP : Ts{1,sizeof.=
...(Ts)}...<br><br>N4144: Ts.[N]<br>ATPP: Ts{N}<br><br><pre>N4144: Ts.&lt;(0=
 ...&lt; sizeof...(Ts)), (0 ...&lt; sizeof...(Ts))&gt;</pre>ATPP: Ts{}[2]..=
..<br><br>For the record, Vandevoorde's expansion does not cover what happen=
s when F&lt;Ts&gt;... is the intention (valid C++ construct applying F over=
 the Ts pack), nor the actual issue behind the addition of other expression=
s to sizeof...(Ts) in relation to eventually recursive use of such construc=
t. ATPP does. In relation to the F&lt;X&gt;... construct I am referring to =
(which in the end proves the haskellian fmap-like character of this valid C=
++ rule):<br><br>#include &lt;cstdio&gt;<br>template&lt;typename...&gt; str=
uct Helper {};<br><br>template&lt;template&lt;typename...&gt; class F, type=
name... X&gt;<br>void fun(F&lt;X&gt;...)<br>{ printf("hello, world\n"); }<b=
r><br>int main() {<br>&nbsp;&nbsp;&nbsp; fun(Helper&lt;int&gt;(), Helper&lt=
;long&gt;(), Helper&lt;char&gt;());<br>&nbsp;&nbsp;&nbsp; return 0;<br>}<br=
><br>It is interesting to note that Vandevoorde's approach is for generatin=
g integer sequences for pack accessing over specifying them as range/interv=
al endpoints to achieve the same effect of ATPP but with increased verbosit=
y and parsing requirements while also introducing another construct for int=
eger generation.<br><br>People designing libraries for packs (like <b>std::=
packer</b>), should take under consideration things like N4144 or other pro=
posals coming about based on prior work given that we are talking about C++=
17 and past that for general use. Any extension to packs (which the multitu=
de of experienced C++ programmers desire) does not overlap with concepts, g=
iven that pack processing is capable of far more than providing a means for=
 bounded parametric polymorphism to be "worked" around into the language. S=
uch additions will greatly enhance the uncanny and arcanely "evil" usefulne=
ss of templates, to the absolute horror of their creator. Think of what hap=
pens when the output of constexpr functions is used as input for such integ=
ral constant expression pack syntax in combination to the beloved concepts.=
 Packs need to be provided with a language level access interface so that m=
ore useful constructs can be made, regardless of who is behind it.<br><br>L=
ibraries (such as the proposed <b>std::packer</b>) using such features will=
 be more powerful because they will be able to systematically provide pack =
manipulation at a lower instantiation (both in boilerplate and compiler int=
ernals) cost, opening up pandora's box for twisting the language into absur=
dly unnatural but highly expressive code. Therefore, certain EWG deliberati=
ons on "library recommendations" to prior work like the one done in atpp, a=
re misleading, if an EWG member who was "against" them picks up on their ex=
act technical substance. Either way, serious template metaprogrammers get w=
hat they want, on a programming style concretely presented initially by Erw=
in Unruh long time ago. I foresee a set of features proposed by different p=
eople, previously fearful of "complexity", to be bundled together into form=
ing the substance of pack annotation (atpp) soon enough, given that all of =
this background interplay is finally giving priority to an active EWG issue=
 for more than two years. In the end, this was not a question of technical =
completeness and adequacy, but a question of leverage leading to pyrrhic vi=
ctories.<br><br>I look forward to seeing the evident outcome of Vandevoorde=
's efforts and be flattered more by them. I think that a library like std::=
packer propose should take into serious consideration ongoing work in the E=
WG in order to resolve to an implementation that takes into the account C++=
17 (?) developments at the language level without wasting their time. Wheth=
er there is std::tuple overlap (as elsewhere implied by other authors) is i=
rrelevant because std::tuple is "worked around" into fitting parameter pack=
 manipulation for the lack of boost::mpl::vector like features and is not a=
 first-class library feature for such things.<br><br>Thank you for your tim=
e and consideration.<br><br>George<br><br>On Tuesday, October 14, 2014 10:0=
2:54 PM UTC+3, Sean Middleditch wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><font face=3D"arial, sans-serif" size=3D"2">As par=
t of N4144, it would be incredibly useful to include the abilities to get t=
he index of a type in a pack (first occurance at least) and to get a type a=
t an index. It allows for some very powerful compile-time transformations n=
ecessary to support a variadic container type (e.g. boost::variadic) withou=
t requiring RTTI (which is important for a variant to be useful to the many=
 domains of users that use -fno-rtti or equivalent for various reasons).</f=
ont><div><font face=3D"arial, sans-serif" size=3D"2"><br></font></div><div>=
<font face=3D"arial, sans-serif" size=3D"2">In a previous small paper I pro=
posed type_at&lt;&gt;, which I meant to submit an update to this time but g=
ot distracted with that pesky "job" thing, which would have addressed the c=
ommittee's feedback on the original proposal as well as add a type_index_of=
&lt;&gt; template. I don't have the implementations easily accessible at th=
e moment, but they're both very simple sets of templates, and as per commit=
tee feedback trigger SFINAE rather than hard errors on any failure (if you =
index past the end of a parameter pack or if you ask for the index of a typ=
e not present). If the idea is to move most uses of type lists to the packe=
r type in N4144 then it should provide those operations.</font></div><div><=
font size=3D"2"><br></font></div><div><font face=3D"arial, sans-serif" size=
=3D"2">Summary: please consider adding<span style=3D"color:rgb(0,0,0)">&nbs=
p;an index_of&lt;typename T, packer&lt;...&gt;&gt; that returns a std::inte=
gral_constant&lt;size_t, N&gt; where N is the first "index" into the parame=
ter pack of the requested type, and add a type_at&lt;packer&lt;...&gt;, siz=
e_t N&gt; that maps an index to a type at the given index, with SFINAE fail=
ures in both cases the requested type or index is invalid.</span></font></d=
iv></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_2124_848801996.1413369148285--

.