------=_Part_2374_1695685651.1410745534388
Content-Type: text/plain; charset=UTF-8

I'm finally getting off my duff and writing a followup to N3761 from last
year.

https://github.com/seanmiddleditch/CPlusPlus/blob/master/type-list-indexing.md

I would like to float this update past the crazy smart people here before I
go too much further with.

The hardest part for me is figuring out how to write the standard document
changes this would require. I'm not sure it's worth doing for what is
essentially a whole new proposal until after I get back the committee's
initial response.


Type List Indexing
==================

 - Document Number : NXXXX - 09-2014
 - Date            : 2014-09-XX
 - Project         : Programming Language C++, Evolution Working Group
 - Reply-to        : Sean Middleditch <sean@...>

***

Summary
-------

This proposal is in response to feedback from [N3761]. This proposal introduces a language change that
allows for easy and direct access to any member of a parameter pack using a constant expression integral
value.

This facility combined with `sizeof...`, `std::integer_sequence`, and `constexpr` functions would allow
for simpler transformations of parameter packs and algorithms without requiring the use of recursion
where iteration may be the preferred implementation approach.

Motivation and Use Cases
------------------------

Various algorithms over parameter packs currently must be implemented as a recursive series of function
or template invocations. This is often not the most natural or obvious way of implementing the algorithm.

By allowing direct access to the element of a parameter pack by index, loops may be written over the
pack. Example:

    template <typename ...Ts>
    constexpr bool all(Ts&&... ts)
    {
      // check if any member of ts evaluates to false
      for (auto index = 0U; index != sizeof...(ts); ++index)
        if (!ts...[index])
       return false;

      // either all members evaluated to true or there were no members; only succeed in former case
      return sizeof...(ts) != 0;
    }

There are also cases where a user may only wish to iterate over part of a parameter pack such as when
performing a binary search. This case is far more difficult to do with recursive template expansion
than it would be if direct index access were allowed.

Alternatives
------------

The alternatives are the option presented in [N3761] or its alternatives.

### std::tuple

A user can convert a parameter pack into a tuple and then use `std::get<>` to access the nth element.

This technique is a little verbose and is not immediately obvious. This will contribute to the general
consensus that C++ template programming is difficult and only for experts.

### type_at

A small library addition would provide `std::type_at<N, Ts...>::type` and `std::value_at<N>(pack...)`.
These can of course have C++14 style aliases such as `type_at_t`.

The original comments included a note by Bjarne Stroustrup that the sample implementation provided would
execute in O(N) compile time. `std::integer_sequence` provides some implementation insight on how to
reduce this to O(log(N)) or that an implementation could use vendor-specific built-ins to implement this
in O(1).

This proposal provides O(1) access using a standard syntax in place of an implementation-specific
feature backing a library interface.

Example Syntax
--------------

The proposed syntax looks like:

    // context: template <typename ...Ts>
    using third_type = Ts...[2];

    // context: template <typename ...Ts> void function(Ts... ts)
    auto fourth_value = ts...[3];

Standard Document Additions
---------------------------

**help needed**

Acknowledgements
----------------

In comments [N3761], Richard Smith presented a strawman syntax proposing a language approach as
alternative to the library approach presented. I used that as a trampoline for this paper.

Bjarne Stroustrup illustrated the computational complexity problems with a pure library approach
compared to a core language approach.

**help needed** This same syntax was floated in response to another paper submitted to the committee
sometime in the last year, but I have completely forgotten which paper or who made the suggestion,
and I'd like to give credit.



  [N3761]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3761.html "Proposing type_at<>"

--

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

<div dir=3D"ltr"><div>I'm finally getting off my duff and writing a followu=
p to N3761 from last year.</div><div><br></div>https://github.com/seanmiddl=
editch/CPlusPlus/blob/master/type-list-indexing.md<br><div><br></div><div>I=
 would like to float this update past the crazy smart people here before I =
go too much further with.</div><div><br></div><div>The hardest part for me =
is figuring out how to write the standard document changes this would requi=
re. I'm not sure it's worth doing for what is essentially a whole new propo=
sal until after I get back the committee's initial response.</div><div><br>=
</div><div><br></div><div><pre style=3D"color: rgb(0, 0, 0);">Type List Ind=
exing
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 - Document Number : NXXXX - 09-2014
 - Date            : 2014-09-XX
 - Project         : Programming Language C++, Evolution Working Group
 - Reply-to        : Sean Middleditch &lt;sean@...&gt;

***

Summary
-------

This proposal is in response to feedback from [N3761]. This proposal introd=
uces a language change that
allows for easy and direct access to any member of a parameter pack using a=
 constant expression integral
value.

This facility combined with `sizeof...`, `std::integer_sequence`, and `cons=
texpr` functions would allow
for simpler transformations of parameter packs and algorithms without requi=
ring the use of recursion
where iteration may be the preferred implementation approach.

Motivation and Use Cases
------------------------

Various algorithms over parameter packs currently must be implemented as a =
recursive series of function
or template invocations. This is often not the most natural or obvious way =
of implementing the algorithm.

By allowing direct access to the element of a parameter pack by index, loop=
s may be written over the
pack. Example:

    template &lt;typename ...Ts&gt;
    constexpr bool all(Ts&amp;&amp;... ts)
    {
      // check if any member of ts evaluates to false
      for (auto index =3D 0U; index !=3D sizeof...(ts); ++index)
        if (!ts...[index])
       return false;
      =20
      // either all members evaluated to true or there were no members; onl=
y succeed in former case
      return sizeof...(ts) !=3D 0;
    }

There are also cases where a user may only wish to iterate over part of a p=
arameter pack such as when
performing a binary search. This case is far more difficult to do with recu=
rsive template expansion
than it would be if direct index access were allowed.

Alternatives
------------

The alternatives are the option presented in [N3761] or its alternatives.

### std::tuple

A user can convert a parameter pack into a tuple and then use `std::get&lt;=
&gt;` to access the nth element.

This technique is a little verbose and is not immediately obvious. This wil=
l contribute to the general
consensus that C++ template programming is difficult and only for experts.

### type_at

A small library addition would provide `std::type_at&lt;N, Ts...&gt;::type`=
 and `std::value_at&lt;N&gt;(pack...)`.
These can of course have C++14 style aliases such as `type_at_t`.

The original comments included a note by Bjarne Stroustrup that the sample =
implementation provided would
execute in O(N) compile time. `std::integer_sequence` provides some impleme=
ntation insight on how to
reduce this to O(log(N)) or that an implementation could use vendor-specifi=
c built-ins to implement this
in O(1).

This proposal provides O(1) access using a standard syntax in place of an i=
mplementation-specific
feature backing a library interface.
=09
Example Syntax
--------------

The proposed syntax looks like:

    // context: template &lt;typename ...Ts&gt;
    using third_type =3D Ts...[2];
   =20
    // context: template &lt;typename ...Ts&gt; void function(Ts... ts)
    auto fourth_value =3D ts...[3];
=09
Standard Document Additions
---------------------------

**help needed**

Acknowledgements
----------------

In comments [N3761], Richard Smith presented a strawman syntax proposing a =
language approach as
alternative to the library approach presented. I used that as a trampoline =
for this paper.

Bjarne Stroustrup illustrated the computational complexity problems with a =
pure library approach
compared to a core language approach.

**help needed** This same syntax was floated in response to another paper s=
ubmitted to the committee
sometime in the last year, but I have completely forgotten which paper or w=
ho made the suggestion,
and I'd like to give credit.

=09
=09
  [N3761]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3761.ht=
ml "Proposing type_at&lt;&gt;"</pre></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_2374_1695685651.1410745534388--

.

------=_Part_5_840411554.1410747014064
Content-Type: text/plain; charset=UTF-8



template <typename ...Ts>
constexpr bool all(Ts&&... ts)
{
    // check if any member of ts evaluates to false
    for (auto index = 0U; index != sizeof...(ts); ++index)
      if (!ts...[index])
        return false;

    // either all members evaluated to true or there were no members; only succeed in former case
    return sizeof...(ts) != 0;
}


How would the language machinery have to be modified so that index would be
a constexpr?
Wouldn't it be better in that case to provide only a ranged-for based
iteration, and somehow special-case that to provide the constexpr
guarantees?

Sorry if that question seems off the mark, It's the first time I have
considered this problem.

--

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

<div dir=3D"ltr"><div class=3D"prettyprint" style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><pre style=3D"color:rgb(0,0,0)"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ts</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">bool</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> all</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Ts</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&amp;&amp;...</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> ts</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp=
; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// check=
 if any member of ts evaluates to false</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> index </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">0U</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> index </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">sizeof</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">ts</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">index</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">ts</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...[</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">index</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">])</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">false</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&nbsp; &nbsp; </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// either all members=
 evaluated to true or there were no members; only succeed in former case</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">sizeof</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">...(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">ts</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></pre></div></co=
de></div><br>How would the language machinery have to be modified so that i=
ndex would be a constexpr?<br>Wouldn't it be better in that case to provide=
 only a ranged-for based iteration, and somehow special-case that to provid=
e the constexpr guarantees?<br><br>Sorry if that question seems off the mar=
k, It's the first time I have considered this problem.<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&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_5_840411554.1410747014064--

.

On Sun, Sep 14, 2014 at 7:10 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
>
> template <typename ...Ts>
> constexpr bool all(Ts&&... ts)
> {
>     // check if any member of ts evaluates to false
>     for (auto index = 0U; index != sizeof...(ts); ++index)
>       if (!ts...[index])
>         return false;
>
>     // either all members evaluated to true or there were no members; only
> succeed in former case
>     return sizeof...(ts) != 0;
> }
>
>
> How would the language machinery have to be modified so that index would be
> a constexpr?
> Wouldn't it be better in that case to provide only a ranged-for based
> iteration, and somehow special-case that to provide the constexpr
> guarantees?

Sigh. Yeah, that may have been a bad over-simplified example. A
range-based for makes way more sense in that case anywhow
semantically, though it would also be totally not supported without
extensions to the constexpr rules. I should whip up a binary search
example instead since that's a stronger use case for this feature I
think anyway.

Something like:

template <typename Value, typename ...Ts>
constexpr auto binary_search(Value& value, Ts&... ts) {
  // base case
  if (sizeof...(ts) == 1)
   return ts...[0];

  constexpr auto pivot = sizeof...(ts) / 2;

  if (value < ts[pivot])
    return binary_search(value, ts[std::make_index_sequence(pivot)]...);
  else
    return binary_search(value, ts[std::make_index_sequence(pivot + 1,
sizeof...(ts))]);
}

Of course, make_integer_sequence with a starting index isn't
supported, is 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/.

.

------=_Part_440_1536090791.1410754944519
Content-Type: text/plain; charset=UTF-8

On Sunday, September 14, 2014 11:27:01 PM UTC-3, Sean Middleditch wrote:
>
>
> Sigh. Yeah, that may have been a bad over-simplified example. A
> range-based for makes way more sense in that case anywhow
> semantically, though it would also be totally not supported without
> extensions to the constexpr rules. I should whip up a binary search
> example instead since that's a stronger use case for this feature I
> think anyway.
>

By the way, you should take a look at boost hana since it's concerned with
solving problems like these.
Specifically, it has a for_each metafunction to iterate over compile-time
lists, being those type lists, value lists, or mixed.
http://ldionne.github.io/hana/structboost_1_1hana_1_1_foldable.html#a80176fbdfbccc09e902263557eb0984d

You can find the rest of boost hana starting from:
https://github.com/ldionne/hana


>
> Something like:
>
> template <typename Value, typename ...Ts>
> constexpr auto binary_search(Value& value, Ts&... ts) {
>   // base case
>   if (sizeof...(ts) == 1)
>    return ts...[0];
>
>   constexpr auto pivot = sizeof...(ts) / 2;
>
>   if (value < ts[pivot])
>     return binary_search(value, ts[std::make_index_sequence(pivot)]...);
>   else
>     return binary_search(value, ts[std::make_index_sequence(pivot + 1,
> sizeof...(ts))]);
> }
>
> Of course, make_integer_sequence with a starting index isn't
> supported, is it? :/
>

That's better indeed! Still maybe you can find some more powerful
implementation of make_index_sequence on hana, although I never looked for
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/.

------=_Part_440_1536090791.1410754944519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, September 14, 2014 11:27:01 PM UTC-3, Sean Midd=
leditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Sigh. Yeah, =
that may have been a bad over-simplified example. A
<br>range-based for makes way more sense in that case anywhow
<br>semantically, though it would also be totally not supported without
<br>extensions to the constexpr rules. I should whip up a binary search
<br>example instead since that's a stronger use case for this feature I
<br>think anyway.
<br></blockquote><div><br>By the way, you should take a look at boost hana =
since it's concerned with solving problems like these.<br>Specifically, it =
has a for_each metafunction to iterate over compile-time lists, being those=
 type lists, value lists, or mixed.<br>http://ldionne.github.io/hana/struct=
boost_1_1hana_1_1_foldable.html#a80176fbdfbccc09e902263557eb0984d<br><br>Yo=
u can find the rest of boost hana starting from: https://github.com/ldionne=
/hana<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Something like:
<br>
<br>template &lt;typename Value, typename ...Ts&gt;
<br>constexpr auto binary_search(Value&amp; value, Ts&amp;... ts) {
<br>&nbsp; // base case
<br>&nbsp; if (sizeof...(ts) =3D=3D 1)
<br>&nbsp; &nbsp;return ts...[0];
<br>
<br>&nbsp; constexpr auto pivot =3D sizeof...(ts) / 2;
<br>
<br>&nbsp; if (value &lt; ts[pivot])
<br>&nbsp; &nbsp; return binary_search(value, ts[std::make_index_sequence(<=
wbr>pivot)]...);
<br>&nbsp; else
<br>&nbsp; &nbsp; return binary_search(value, ts[std::make_index_sequence(<=
wbr>pivot + 1,
<br>sizeof...(ts))]);
<br>}
<br>
<br>Of course, make_integer_sequence with a starting index isn't
<br>supported, is it? :/<br></blockquote><div><br>That's better indeed! Sti=
ll maybe you can find some more powerful implementation of make_index_seque=
nce on hana, although I never looked for it.<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&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_440_1536090791.1410754944519--

.

On Sun, Sep 14, 2014 at 9:22 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Sunday, September 14, 2014 11:27:01 PM UTC-3, Sean Middleditch wrote:
>>
>>
>> Sigh. Yeah, that may have been a bad over-simplified example. A
>> range-based for makes way more sense in that case anywhow
>> semantically, though it would also be totally not supported without
>> extensions to the constexpr rules. I should whip up a binary search
>> example instead since that's a stronger use case for this feature I
>> think anyway.
>
>
> By the way, you should take a look at boost hana since it's concerned with
> solving problems like these.

Well, part of the goal would be to make it possible for something like
hana to be implemented with fewer lines of code and faster compilation
speeds. Hana is a use case, not a solution. :)

--
Sean Middleditch
http://seanmiddleditch.com

--

---
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_2101_1881947633.1410758391616
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 1:32:27 AM UTC-3, Sean Middleditch wrote:

>
> Well, part of the goal would be to make it possible for something like
> hana to be implemented with fewer lines of code and faster compilation
> speeds. Hana is a use case, not a solution. :)
>

Point taken! But if a constexpr range-based for ever gets standardized,
it would be a shame if it becomes something that is limited to parameter
packs and a few other things.
It should be possible to iterate over a hana foldable without having to
resort to a custom for_each thing as the interface.
But I am sure you are going to have that covered :)

--

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

<div dir=3D"ltr">On Monday, September 15, 2014 1:32:27 AM UTC-3, Sean Middl=
editch wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Well, part of the goal would be to make it possible for something like
<br>hana to be implemented with fewer lines of code and faster compilation
<br>speeds. Hana is a use case, not a solution. :)
<br></blockquote><div><br>Point taken! But if a constexpr range-based for e=
ver gets standardized,<br>it would be a shame if it becomes something that =
is limited to parameter packs and a few other things.<br>It should be possi=
ble to iterate over a hana foldable without having to resort to a custom fo=
r_each thing as the interface.<br>But I am sure you are going to have that =
covered :)<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&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_2101_1881947633.1410758391616--

.

------=_Part_3245_206524393.1410798167255
Content-Type: text/plain; charset=UTF-8

I updated the paper with the different example. Thanks Matheus!

On Sunday, September 14, 2014 9:22:24 PM UTC-7, Matheus Izvekov wrote:
>
> That's better indeed! Still maybe you can find some more powerful
> implementation of make_index_sequence on hana, although I never looked for
> 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/.

------=_Part_3245_206524393.1410798167255
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I updated the paper with the different example. Thanks Mat=
heus!<br><br>On Sunday, September 14, 2014 9:22:24 PM UTC-7, Matheus Izveko=
v wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
That's better indeed! Still maybe you can find some more powerful implement=
ation of make_index_sequence on hana, although I never looked for it.<br></=
div></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_3245_206524393.1410798167255--

.

This is a multi-part message in MIME format.
--------------030001020107080506060607
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/15/2014 04:45 AM, Sean Middleditch wrote:
> I'm finally getting off my duff and writing a followup to N3761 from
> last year.
>
> https://github.com/seanmiddleditch/CPlusPlus/blob/master/type-list-indexing.md
>
> I would like to float this update past the crazy smart people here
> before I go too much further with.
>
>
[ ... snip ... ]

>
> Acknowledgements
> ----------------
>
> In comments [N3761], Richard Smith presented a strawman syntax proposing a language approach as
> alternative to the library approach presented. I used that as a trampoline for this paper.
>
> Bjarne Stroustrup illustrated the computational complexity problems with a pure library approach
> compared to a core language approach.

Though /I am fully aware/ that this is going to get ignored, I'd like to
mention the alternative route that is being worked upon which covers
this scenario. Stroustrup and Sutton were for giving ATPP (annotated
template parameter packs) a library approach over a core language one,
which is interesting in view of their deliberation on N3761 you mention
here. Two comments on ...[N] syntax follow after it.

The proposed syntax for typelist access by index AND range in my case is:

// index-based access at N
template<std::size_t N, typename... T>
struct type_at {
     typedef T{N} type;
};

// range-based expansion in [N,K)
template<std::size_t N, std::size K, typename... T>
struct range_apply {
     template<typename...> class F>
     using type = F<T{N,K}>;
};

The use of {} in the use cases presented is currently syntax that is
unambiguous and can be exploited for compiler implementation through the
lack of triple-dot association in the proposed syntax; the latter would
currently raise an error if used as such (a hint of where a branching
statement for an AST based compiler can be placed).

In my case, I reserve triple-dot associated syntax for other, more
complex matching by pack size, size range and patterns included in the
pack. This way you get syntax that is terse enough to manipulate
parameter packs in several cases where parameter list matching is
involved, not just for index/range-access.

Now, two comments to make here on ...[N] syntax for individual access in
relation to the work you are doing:

 1. Just allowing index-based access is not enough: working over a range
    of types in a parameter pack would still require recursive template
    instantiations, which is one of the things to avoid if you really
    wish to lower computational complexity.
 2. Syntax like ...[N] for access /within a template parameter list of
    an enclosed template/, may be ambiguous (for example in non-type
    parameter packs) as other alternatives are currently finding out.

Regardless of the work on ATPP, I think that linking triple-dot to
individual access is going to lead to additional syntactical
complexities for any future extensions to parameter pack notation
/within a template parameter list whether for fixed sizes, size ranges/
or /patterns /involved.
>
> **help needed** This same syntax was floated in response to another paper submitted to the committee
> sometime in the last year, but I have completely forgotten which paper or who made the suggestion,
> and I'd like to give credit.
>

Current status of the work at : https://github.com/irrequietus/atpp. The
plan is to complete the necessary wording by the next deadline and get a
number. Given all the interest in extending parameter pack expansion, it
is bewildering why a unified syntactical approach over EWG#30 was not
"encouraged", while it also validates what ATPP is already exploring
(and eventually proposing) in previous drafts.

Thanks for providing paper trail for EWG's conflicting views and good luck.

Regards,

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/.

--------------030001020107080506060607
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">
    <br>
    <div class=3D"moz-cite-prefix">On 09/15/2014 04:45 AM, Sean
      Middleditch wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:f1ffb06d-9ede-4244-828a-fa37a8d3f8d9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>I'm finally getting off my duff and writing a followup to
          N3761 from last year.</div>
        <div><br>
        </div>
<a class=3D"moz-txt-link-freetext" href=3D"https://github.com/seanmiddledit=
ch/CPlusPlus/blob/master/type-list-indexing.md">https://github.com/seanmidd=
leditch/CPlusPlus/blob/master/type-list-indexing.md</a><br>
        <div><br>
        </div>
        <div>I would like to float this update past the crazy smart
          people here before I go too much further with.</div>
        <div><br>
        </div>
        <br>
      </div>
    </blockquote>
    [ ... snip ... ]<br>
    <br>
    <blockquote
      cite=3D"mid:f1ffb06d-9ede-4244-828a-fa37a8d3f8d9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <pre style=3D"color: rgb(0, 0, 0);">

Acknowledgements
----------------

In comments [N3761], Richard Smith presented a strawman syntax proposing a =
language approach as
alternative to the library approach presented. I used that as a trampoline =
for this paper.

Bjarne Stroustrup illustrated the computational complexity problems with a =
pure library approach
compared to a core language approach.</pre>
        </div>
      </div>
    </blockquote>
    <br>
    Though <i>I am fully aware</i> that this is going to get ignored,
    I'd like to mention the alternative route that is being worked upon
    which covers this scenario. Stroustrup and Sutton were for giving
    ATPP (annotated template parameter packs) a library approach over a
    core language one, which is interesting in view of their
    deliberation on N3761 you mention here. Two comments on ...[N]
    syntax follow after it.<br>
    <br>
    The proposed syntax for typelist access by index AND range in my
    case is:<br>
    <br>
    // index-based access at N<br>
    template&lt;std::size_t N, typename... T&gt;<br>
    struct type_at {<br>
    =C2=A0=C2=A0=C2=A0 typedef T{N} type;<br>
    };<br>
    <br>
    // range-based expansion in [N,K)<br>
    template&lt;std::size_t N, std::size K, typename... T&gt;<br>
    struct range_apply {<br>
    =C2=A0=C2=A0=C2=A0 template&lt;typename...&gt; class F&gt;<br>
    =C2=A0=C2=A0=C2=A0 using type =3D F&lt;T{N,K}&gt;;<br>
    };<br>
    <br>
    The use of {} in the use cases presented is currently syntax that is
    unambiguous and can be exploited for compiler implementation through
    the lack of triple-dot association in the proposed syntax; the
    latter would currently raise an error if used as such (a hint of
    where a branching statement for an AST based compiler can be
    placed).<br>
    <br>
    In my case, I reserve triple-dot associated syntax for other, more
    complex matching by pack size, size range and patterns included in
    the pack. This way you get syntax that is terse enough to manipulate
    parameter packs in several cases where parameter list matching is
    involved, not just for index/range-access.<br>
    <br>
    Now, two comments to make here on ...[N] syntax for individual
    access in relation to the work you are doing:<br>
    <ol>
      <li>Just allowing index-based access is not enough: working over a
        range of types in a parameter pack would still require recursive
        template instantiations, which is one of the things to avoid if
        you really wish to lower computational complexity.</li>
      <li>Syntax like ...[N] for access <i>within a template parameter
          list of an enclosed template</i>, may be ambiguous (for
        example in non-type parameter packs) as other alternatives are
        currently finding out.<br>
      </li>
    </ol>
    Regardless of the work on ATPP, I think that linking triple-dot to
    individual access is going to lead to additional syntactical
    complexities for any future extensions to parameter pack notation <i>wi=
thin
      a template parameter list whether for fixed sizes, size ranges</i>
    or <i>patterns </i>involved.<br>
    <blockquote
      cite=3D"mid:f1ffb06d-9ede-4244-828a-fa37a8d3f8d9@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <pre style=3D"color: rgb(0, 0, 0);">

**help needed** This same syntax was floated in response to another paper s=
ubmitted to the committee
sometime in the last year, but I have completely forgotten which paper or w=
ho made the suggestion,
and I'd like to give credit.

</pre>
        </div>
      </div>
    </blockquote>
    <br>
    Current status of the work at : <a
      href=3D"https://github.com/irrequietus/atpp">https://github.com/irreq=
uietus/atpp</a>.
    The plan is to complete the necessary wording by the next deadline
    and get a number. Given all the interest in extending parameter pack
    expansion, it is bewildering why a unified syntactical approach over
    EWG#30 was not "encouraged", while it also validates what ATPP is
    already exploring (and eventually proposing) in previous drafts.<br>
    <br>
    Thanks for providing paper trail for EWG's conflicting views and
    good luck.<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <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&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 />

--------------030001020107080506060607--

.

On Mon, Sep 15, 2014 at 11:58 AM, George Makrydakis
<irrequietus@gmail.com> wrote:
>
> Though I am fully aware that this is going to get ignored, I'd like to

Oh, not at all.

I had no idea that there was an active EWG issue for this stuff and
that lots of better thinkers than me have been looking at the problem.
And I had somehow not heard of ATPP before this.

> mention the alternative route that is being worked upon which covers this
> scenario. Stroustrup and Sutton were for giving ATPP (annotated template
> parameter packs) a library approach over a core language one, which is
> interesting in view of their deliberation on N3761 you mention here. Two
> comments on ...[N] syntax follow after it.

They'd prefer to keep as much in the library as possible, but some of
the underlying support needs compiler intervention. They also did
mention the possibility of an intrinsic backing type_at<> or the like;
you might consider mentioning that as a possible "syntax" rather than
just focusing on a particular language change (if you haven't already;
haven't read your paper yet but I will shortly).

Honestly, the reason I originally proposed type_at<> and not a
language change was that I was reasonably certain they'd prefer a
library approach! :)

It's definitely clear that a range needs to be supported as well as
just a singular index, which if nothing else is something I'll add to
my paper (assuming I bother to submit it; sounds like you have this
covered).

> **help needed** This same syntax was floated in response to another paper
> submitted to the committee
> sometime in the last year, but I have completely forgotten which paper or
> who made the suggestion,
> and I'd like to give credit.
>
>
> Current status of the work at : https://github.com/irrequietus/atpp. The
> plan is to complete the necessary wording by the next deadline and get a
> number. Given all the interest in extending parameter pack expansion, it is
> bewildering why a unified syntactical approach over EWG#30 was not
> "encouraged", while it also validates what ATPP is already exploring (and
> eventually proposing) in previous drafts.

Awesome. Thanks!
--
Sean Middleditch
http://seanmiddleditch.com

--

---
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/.

.

This is a multi-part message in MIME format.
--------------030804070903070803000203
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/15/2014 10:36 PM, Sean Middleditch wrote:
> Honestly, the reason I originally proposed type_at<> and not a
> language change was that I was reasonably certain they'd prefer a
> library approach! :) It's definitely clear that a range needs to be
> supported as well as just a singular index, which if nothing else is
> something I'll add to my paper (assuming I bother to submit it; sounds
> like you have this covered).
Thanks for replying! I think that library approaches are slightly
inappropriate when it comes to parameter pack access because they only
lead us into more recursive template instantiations. But I see the
strategy there!

Whatever any proposal does with packs, it must avoid forcing the end
user to use recursive template instantiations for working with them for
trivial things (size, access etc); Abrahams is right in pointing this
out in EWG#30.

I really hope we eventually have packs becoming first-class language
supported constructs in all their aspects (size, access etc). It is such
a shame not having them as such in the only widespread language that has
turing completeness in its ad-hoc parametric polymorphism (templates).
But both syntax and semantics can be very tricky and the "little
additions" approach favored by some is only going to lead us to
fragmented or increasingly context-dependent syntax that will break
under its own weight.

/That is why this is a really complicated issue that perhaps should
require a SG for it; I don't know if anybody has actually thought of
this eventuality./

Regards,

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/.

--------------030804070903070803000203
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 09/15/2014 10:36 PM, Sean
      Middleditch wrote:<br>
    </div>
    <blockquote
cite="mid:CALQmNFjxJzX7MvEosWgG5Si+c-ctd-nCsGRf-5nsWHwe7+sBvg@mail.gmail.com"
      type="cite">
      Honestly, the reason I originally proposed type_at&lt;&gt; and not
      a
      language change was that I was reasonably certain they'd prefer a
      library approach! :)
      It's definitely clear that a range needs to be supported as well
      as
      just a singular index, which if nothing else is something I'll add
      to
      my paper (assuming I bother to submit it; sounds like you have
      this
      covered).</blockquote>
    Thanks for replying! I think that library approaches are slightly
    inappropriate when it comes to parameter pack access because they
    only lead us into more recursive template instantiations. But I see
    the strategy there!<br>
    <br>
    Whatever any proposal does with packs, it must avoid forcing the end
    user to use recursive template instantiations for working with them
    for trivial things (size, access etc); Abrahams is right in pointing
    this out in EWG#30.<br>
    <br>
    I really hope we eventually have packs becoming first-class language
    supported constructs in all their aspects (size, access etc). It is
    such a shame not having them as such in the only widespread language
    that has turing completeness in its ad-hoc parametric polymorphism
    (templates). But both syntax and semantics can be very tricky and
    the "little additions" approach favored by some is only going to
    lead us to fragmented or increasingly context-dependent syntax that
    will break under its own weight.<br>
    <br>
    <i>That is why this is a really complicated issue that perhaps
      should require a SG for it; I don't know if anybody has actually
      thought of this eventuality.</i><br>
    <br>
    Regards,<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&quot; 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 />

--------------030804070903070803000203--

.

On Mon, Sep 15, 2014 at 12:52 PM, George Makrydakis
<irrequietus@gmail.com> wrote:
>
> On 09/15/2014 10:36 PM, Sean Middleditch wrote:
>
> Honestly, the reason I originally proposed type_at<> and not a language
> change was that I was reasonably certain they'd prefer a library approach!
> :) It's definitely clear that a range needs to be supported as well as just
> a singular index, which if nothing else is something I'll add to my paper
> (assuming I bother to submit it; sounds like you have this covered).
>
> Thanks for replying! I think that library approaches are slightly
> inappropriate when it comes to parameter pack access because they only lead
> us into more recursive template instantiations. But I see the strategy
> there!

I think you can take a bit of a tricky approach here, though. You can
provide a library-like interface that is intended to be backed by
compiler intrinsics. The sales pitch can be "here's a pure-library
implementation, but if you replace this and that bits in the
implementation with intrinsics, you get a huge performance advantage."

I half suspect that to be the reply to the ...[N] syntax and even
considered just tossing it in the first version as an alternative.

I think there may be some advantages to users, too. Considering your
....T{N,M}[K] syntax for instance, that's just really obtuse and hard
to read to me. It's not clear which number is what. A library approach
could be a bit clearer and a high-quality implementation could rely on
intrinsics to have roughly identical performance.

e.g. std::type_at<> could have the inefficient but working
implementation I originally proposed in N3761 but then also clearly
state that high-quality implementation would likely be implemented as:

template <size_t N, typename ...R>
using type_at = __compiler_intrinic<N, R...>;

and likewise for value_at and some type list slice/concat operations.

100% library code that could even be cut-n-paste out of the paper into
an implementation that's trying to bootstrap into C++1z conformance
but for which "real" compilers can optimize away into
language-semantic speeds.

> turing completeness in its ad-hoc parametric polymorphism (templates). But
> both syntax and semantics can be very tricky and the "little additions"
> approach favored by some is only going to lead us to fragmented or
> increasingly context-dependent syntax that will break under its own weight.

I agree. This is also another advantage of preferring the library
veneer API rather than core language changes. It has less impact on
long-term evolution.

--

---
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_852_2071896291.1410829967571
Content-Type: text/plain; charset=UTF-8

On Monday, 15 September 2014 16:29:08 UTC-4, Sean Middleditch wrote:

[...]

> I think you can take a bit of a tricky approach here, though. You can
> provide a library-like interface that is intended to be backed by
> compiler intrinsics. The sales pitch can be "here's a pure-library
> implementation, but if you replace this and that bits in the
> implementation with intrinsics, you get a huge performance advantage."

[...]

Based on the experience of writing Boost.Hana, my opinion is that we do not
want a better support for parameter packs, at least not "officially". Let me
explain.

Parameter packs do not compose very well because they are not a single
entity,
and they are bound to express something isomorphic (via hand waving) to
std::tuple. However, there are several other data structures that are useful
when metaprogramming. For example, one could imagine a tree containing
heterogeneous objects, which could be useful for expression templates.

Of course, parameter packs are useful to make some APIs more usable.
However,
why would we want to do complex parameter pack processing behind that API?
My
guess is that if we had high level ways to manipulate std::tuple (or a
type-level
equivalent), the need for complex manipulation of parameter packs would be
gone.
And if we pick a decently generic and well-thought interface for
std::tuple, it
could then be extended by external libraries handling trees and whatnot.
Hence,
I would prefer improving the interface of std::tuple rather than improving
that
of parameter packs.

That being said, a valid objection would be the compile-time performance of
std::tuple, which is really bad. I think this is a problem in itself and it
ought to be addressed, but not by introducing a new construct that would
address this issue only. If you look at Hana's implementation, the dirty
tricks are very rare [1], and it would be easy to handle some of these with
compiler-dependent intrinsics.

TL;DR
For what it's worth, I would favor a well-thought library approach with
(possibly) a compiler-backed implementation more than a change to the
core language.

Regards,
Louis

[1]:
https://github.com/ldionne/hana/tree/master/include/boost/hana/detail/variadic

--

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

<div dir=3D"ltr"><div><div>On Monday, 15 September 2014 16:29:08 UTC-4, Sea=
n Middleditch wrote:</div><div><br></div><div>[...]</div><div><br></div><di=
v>&gt; I think you can take a bit of a tricky approach here, though. You ca=
n&nbsp;</div><div>&gt; provide a library-like interface that is intended to=
 be backed by&nbsp;</div><div>&gt; compiler intrinsics. The sales pitch can=
 be "here's a pure-library&nbsp;</div><div>&gt; implementation, but if you =
replace this and that bits in the&nbsp;</div><div>&gt; implementation with =
intrinsics, you get a huge performance advantage."&nbsp;</div><div><br></di=
v><div>[...]</div><div><br></div><div>Based on the experience of writing Bo=
ost.Hana, my opinion is that we do not</div><div>want a better support for =
parameter packs, at least not "officially". Let me</div><div>explain.</div>=
<div><br></div><div>Parameter packs do not compose very well because they a=
re not a single entity,</div><div>and they are bound to express something i=
somorphic (via hand waving) to</div><div>std::tuple. However, there are sev=
eral other data structures that are useful</div><div>when metaprogramming. =
For example, one could imagine a tree containing&nbsp;</div><div>heterogene=
ous objects, which could be useful for expression templates.</div><div><br>=
</div><div>Of course, parameter packs are useful to make some APIs more usa=
ble. However,</div><div>why would we want to do complex parameter pack proc=
essing behind that API? My&nbsp;</div><div>guess is that if we had high lev=
el ways to manipulate std::tuple (or a type-level&nbsp;</div><div>equivalen=
t), the need for complex manipulation of parameter packs would be gone.</di=
v><div>And if we pick a decently generic and well-thought interface for std=
::tuple, it</div><div>could then be extended by external libraries handling=
 trees and whatnot. Hence,&nbsp;</div><div>I would prefer improving the int=
erface of std::tuple rather than improving that&nbsp;</div><div>of paramete=
r packs.</div><div><br></div><div>That being said, a valid objection would =
be the compile-time performance of</div><div>std::tuple, which is really ba=
d. I think this is a problem in itself and it</div><div>ought to be address=
ed, but not by introducing a new construct that would&nbsp;</div><div>addre=
ss this issue only. If you look at Hana's implementation, the dirty&nbsp;</=
div><div>tricks are very rare [1], and it would be easy to handle some of t=
hese with&nbsp;</div><div>compiler-dependent intrinsics.</div><div><br></di=
v><div>TL;DR&nbsp;</div><div>For what it's worth, I would favor a well-thou=
ght library approach with</div><div>(possibly) a compiler-backed implementa=
tion more than a change to the&nbsp;</div><div>core language.</div><div><br=
></div><div>Regards,</div><div>Louis</div><div><br></div><div>[1]: https://=
github.com/ldionne/hana/tree/master/include/boost/hana/detail/variadic</div=
></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&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_852_2071896291.1410829967571--

.

--Apple-Mail=_AEFAC739-9EF6-4B98-BBB3-19F246039999
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-16, at 9:12 AM, Louis Dionne <ldionne.2@gmail.com> wrote:

> That being said, a valid objection would be the compile-time performance =
of
> std::tuple, which is really bad.

Wrapping a pack as a tuple type, i.e. merely naming std::tuple< T ... >, is=
 essentially zero work for the compiler.

Incurring instantiation of std::tuple when you don't intend to actually con=
struct an object is a metaprogramming error.

Current implementations of std::tuple_index, etc do not incur instantiation=
..

In my experience, a very significant proportion of type-lists requiring met=
aprocessing are also instantiated as runtime tuples.

> I think this is a problem in itself and it
> ought to be addressed, but not by introducing a new construct that would=
=20
> address this issue only. If you look at Hana's implementation, the dirty=
=20
> tricks are very rare [1], and it would be easy to handle some of these wi=
th=20
> compiler-dependent intrinsics.

Indexing the argument type-list of an uninstantiated specialization require=
s walking up to the index, which is O(N). I don't think that's a dirty tric=
k, but an intrinsic for such an operation would be quite reasonable and sim=
ple. Whether that's a worthwhile optimization depends on whether that O(N) =
cost really adds up to actual seconds in practice. I think for most metapro=
grams, more time (not counting instantiation of executable code) is spent i=
n overload resolution.

--=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=_AEFAC739-9EF6-4B98-BBB3-19F246039999
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;09&ndash;16, at 9:12 AM, Louis Dionne &lt;<a href=3D"mailto:ldionne.2=
@gmail.com">ldionne.2@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div><div>That =
being said, a valid objection would be the compile-time performance of</div=
><div>std::tuple, which is really bad. </div></div></div></blockquote><div>=
<br></div><div>Wrapping a pack as a tuple type, i.e. merely naming <font fa=
ce=3D"Courier">std::tuple&lt; T ... &gt;</font>, is essentially zero work f=
or the compiler.</div><div><br></div><div>Incurring instantiation of <font =
face=3D"Courier">std::tuple</font> when you don&rsquo;t intend to actually =
construct an object is a metaprogramming error.</div><div><br></div><div>Cu=
rrent implementations of <font face=3D"Courier">std::tuple_index</font>, et=
c do not incur instantiation.</div><div><br></div><div>In my experience, a =
very significant proportion of type-lists requiring metaprocessing are also=
 instantiated as runtime tuples.</div><br><blockquote type=3D"cite"><div di=
r=3D"ltr"><div><div>I think this is a problem in itself and it</div><div>ou=
ght to be addressed, but not by introducing a new construct that would&nbsp=
;</div><div>address this issue only. If you look at Hana's implementation, =
the dirty&nbsp;</div><div>tricks are very rare [1], and it would be easy to=
 handle some of these with&nbsp;</div><div>compiler-dependent intrinsics.</=
div></div></div></blockquote><div><br></div><div>Indexing the argument type=
-list of an uninstantiated specialization requires walking up to the index,=
 which is O(N). I don&rsquo;t think that&rsquo;s a dirty trick, but an intr=
insic for such an operation would be quite reasonable and simple. Whether t=
hat&rsquo;s a worthwhile optimization depends on whether that O(N) cost rea=
lly adds up to actual seconds in practice. I think for most metaprograms, m=
ore time (not counting instantiation of executable code) is spent in overlo=
ad resolution.</div></div><div><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&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 />

--Apple-Mail=_AEFAC739-9EF6-4B98-BBB3-19F246039999--

.

------=_Part_231_1155619639.1410842932463
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 7:43:02 PM UTC-7, David Krauss wrote:
>
> In my experience, a very significant proportion of type-lists requiring
> metaprocessing are also instantiated as runtime tuples.
>

A part of me is definitely thinking this may be better off as a set of
extensions to std::tuple to just make it easier to use as a type list. All
of the important operations either are already supposed (just in an IMHO
overly-verbose manner) or can be added as a pure library extension, with
compiler intrinsics for implementations that want to win compilation
benchmarks. :)

Another part of me is considering one of the use cases that Richard Smith
presented in his feedback to N3761 that I completely left out of this draft
paper: applying the indexing operation to a parameter pack expandion, e.g.:

  template <typename... Ts>
  void foo(Ts&&... argv) {
    bar(argv)...[2];
  };

  // this line
  foo<A, B, C>(a, b, c);

  // essentially expands into this line
  bar(c);

Reading George's paper, I do believe that is also supported by ATPP. His
paper would make type_at<> become:

  template<std::size_t N, typename... T{}[N < sizeof...(T)]>
  struct type_at {
    using type = T{N};
  };

with no extra boilerplate needed, if I'm understanding it properly.
Additionally, it makes out-of-bounds accesses a SFINAE error which is
something else the committee said they wanted over my original type_at<>.
George's paper also illustrates other basic type list operations.

I could nitpick his chosen syntax but not much else (that's a good thing).

--

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

<div dir=3D"ltr">On Monday, September 15, 2014 7:43:02 PM UTC-7, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word"><div><div>In my experience, a very significant proportion of=
 type-lists requiring metaprocessing are also instantiated as runtime tuple=
s.<br></div></div></div></blockquote><div><br></div><div>A part of me is de=
finitely thinking this may be better off as a set of extensions to std::tup=
le to just make it easier to use as a type list. All of the important opera=
tions either are already supposed (just in an IMHO overly-verbose manner) o=
r can be added as a pure library extension, with compiler intrinsics for im=
plementations that want to win compilation benchmarks. :)</div><div><br></d=
iv><div>Another part of me is considering one of the use cases that Richard=
 Smith presented in his feedback to N3761 that I completely left out of thi=
s draft paper: applying the indexing operation to a parameter pack expandio=
n, e.g.:</div><div><br></div><div>&nbsp; template &lt;typename... Ts&gt;</d=
iv><div>&nbsp; void foo(Ts&amp;&amp;... argv) {</div><div>&nbsp; &nbsp; bar=
(argv)...[2];</div><div>&nbsp; };</div><div><br></div><div>&nbsp; // this l=
ine</div><div>&nbsp; foo&lt;A, B, C&gt;(a, b, c);</div><div><br></div><div>=
&nbsp; // essentially expands into this line</div><div>&nbsp; bar(c);</div>=
<div><br></div><div>Reading George's paper, I do believe that is also suppo=
rted by ATPP. His paper would make type_at&lt;&gt; become:</div><div><br></=
div><div>&nbsp; template&lt;std::size_t N, typename... T{}[N &lt; sizeof...=
(T)]&gt;<br></div><div><div>&nbsp; struct type_at {</div><div>&nbsp; &nbsp;=
 using type =3D T{N};</div><div>&nbsp; };</div></div><div><br></div><div>wi=
th no extra boilerplate needed, if I'm understanding it properly. Additiona=
lly, it makes out-of-bounds accesses a SFINAE error which is something else=
 the committee said they wanted over my original type_at&lt;&gt;. George's =
paper also illustrates other basic type list operations.</div><div><br></di=
v><div>I could nitpick his chosen syntax but not much else (that's a good t=
hing).</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_231_1155619639.1410842932463--

.

------=_Part_250_1116822565.1410870948741
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, 15 September 2014 22:43:02 UTC-4, David Krauss wrote:
> On 2014=E2=80=9309=E2=80=9316, at 9:12 AM, Louis Dionne <ldio...@gmail.co=
m> wrote:
> > [...]
> > I think this is a problem in itself and it
> > ought to be addressed, but not by introducing a new construct that=20
would=20
> > address this issue only. If you look at Hana's implementation, the=20
dirty=20
> > tricks are very rare [1], and it would be easy to handle some of these=
=20
with=20
> > compiler-dependent intrinsics.
>=20
> Indexing the argument type-list of an uninstantiated specialization=20
requires=20
> walking up to the index, which is O(N).

This way of seeing things is naive. Extensive benchmarking shows that the=
=20
mere counting of instantiations is not always the best metric to measure=20
the compile-time performance of an algorithm. For example, see this [1]
benchmark of a `is_one_of` metafunction and the associated=20
implementations[2].
All those curves have a O(N) behavior for the number of instantiations, but
clearly this does not seem to matter for the compilation time.

Also, it is possible to index a tuple without "walking up to the index"
(at least in a recursive manner); see [3].


> I don=E2=80=99t think that=E2=80=99s a dirty trick, but an intrinsic for =
such an=20
operation=20
> would be quite reasonable and simple. Whether that=E2=80=99s a worthwhile=
=20
optimization=20
> depends on whether that O(N) cost really adds up to actual seconds in=20
practice.=20
> I think for most metaprograms, more time (not counting instantiation of=
=20
> executable code) is spent in overload resolution.

The code in [3] is the kind of thing I was calling a "dirty trick". You are=
=20
right, a compiler intrinsic for that would be desirable. Regarding the=20
overall
cost of metaprograms, I think it would be worthwile to benchmark a real=20
code=20
base; compile-time performance is often tricky.

Regards,
Louis

[1]: http://imgur.com/UoQZ7xd
[2]:=20
https://github.com/ldionne/hana-cppcon-2014/tree/gh-pages/code/benchmark/el=
em
[3]:=20
https://github.com/ldionne/hana/blob/master/include/boost/hana/detail/varia=
dic/at.hpp

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

<div dir=3D"ltr"><div>On Monday, 15 September 2014 22:43:02 UTC-4, David Kr=
auss wrote:</div><div>&gt; On 2014=E2=80=9309=E2=80=9316, at 9:12 AM, Louis=
 Dionne &lt;ldio...@gmail.com&gt; wrote:</div><div>&gt; &gt; [...]</div><di=
v>&gt; &gt; I think this is a problem in itself and it</div><div>&gt; &gt; =
ought to be addressed, but not by introducing a new construct that would&nb=
sp;</div><div>&gt; &gt; address this issue only. If you look at Hana's impl=
ementation, the dirty&nbsp;</div><div>&gt; &gt; tricks are very rare [1], a=
nd it would be easy to handle some of these with&nbsp;</div><div>&gt; &gt; =
compiler-dependent intrinsics.</div><div>&gt;&nbsp;</div><div>&gt; Indexing=
 the argument type-list of an uninstantiated specialization requires&nbsp;<=
/div><div>&gt; walking up to the index, which is O(N).</div><div><br></div>=
<div>This way of seeing things is naive. Extensive benchmarking shows that =
the&nbsp;</div><div>mere counting of instantiations is not always the best =
metric to measure&nbsp;</div><div>the compile-time performance of an algori=
thm. For example, see this [1]</div><div>benchmark of a `is_one_of` metafun=
ction and the associated implementations[2].</div><div>All those curves hav=
e a O(N) behavior for the number of instantiations, but</div><div>clearly t=
his does not seem to matter for the compilation time.</div><div><br></div><=
div>Also, it is possible to index a tuple without "walking up to the index"=
</div><div>(at least in a recursive manner); see [3].</div><div><br></div><=
div><br></div><div>&gt; I don=E2=80=99t think that=E2=80=99s a dirty trick,=
 but an intrinsic for such an operation&nbsp;</div><div>&gt; would be quite=
 reasonable and simple. Whether that=E2=80=99s a worthwhile optimization&nb=
sp;</div><div>&gt; depends on whether that O(N) cost really adds up to actu=
al seconds in practice.&nbsp;</div><div>&gt; I think for most metaprograms,=
 more time (not counting instantiation of&nbsp;</div><div>&gt; executable c=
ode) is spent in overload resolution.</div><div><br></div><div>The code in =
[3] is the kind of thing I was calling a "dirty trick". You are&nbsp;</div>=
<div>right, a compiler intrinsic for that would be desirable. Regarding the=
 overall</div><div>cost of metaprograms, I think it would be worthwile to b=
enchmark a real code&nbsp;</div><div>base; compile-time performance is ofte=
n tricky.</div><div><br></div><div>Regards,</div><div>Louis</div><div><br><=
/div><div>[1]: http://imgur.com/UoQZ7xd</div><div>[2]: https://github.com/l=
dionne/hana-cppcon-2014/tree/gh-pages/code/benchmark/elem</div><div>[3]: ht=
tps://github.com/ldionne/hana/blob/master/include/boost/hana/detail/variadi=
c/at.hpp</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_250_1116822565.1410870948741--

.

--Apple-Mail=_C75A69A2-499F-4C9C-96B7-290797512947
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-16, at 8:35 PM, Louis Dionne <ldionne.2@gmail.com> wrote:

> > Indexing the argument type-list of an uninstantiated specialization req=
uires=20
> > walking up to the index, which is O(N).
>=20
> This way of seeing things is naive. Extensive benchmarking shows that the=
=20
> mere counting of instantiations is not always the best metric to measure=
=20
> the compile-time performance of an algorithm. For example, see this [1]
> benchmark of a `is_one_of` metafunction and the associated implementation=
s[2].
> All those curves have a O(N) behavior for the number of instantiations, b=
ut
> clearly this does not seem to matter for the compilation time.

In my experience, performance tends to be roughly proportional to compiler =
memory use, and that is proportional to the total number of data structures=
 you ask for. Your instantiations are not equal there because some require =
larger argument lists. Overload resolution takes time, too, even without SF=
INAE.

Anyway, all big-O notation is naive, it kind of goes without saying :P .

> Also, it is possible to index a tuple without "walking up to the index"
> (at least in a recursive manner); see [3].

Fair nuff, and good idea.

make_index_sequence still needs to "walk" unless it's an intrinsic. However=
, in any case, its result can be memoized.

> The code in [3] is the kind of thing I was calling a "dirty trick". You a=
re=20
> right, a compiler intrinsic for that would be desirable.

I don't see that as being too dirty either. Anyway, my point is that the cu=
rrent core language spec doesn't create a performance bottleneck with pack =
manipulation, so we likely can't expect performance improvements, and any a=
rgument on that basis needs empirical evidence.

> Regarding the overall
> cost of metaprograms, I think it would be worthwile to benchmark a real c=
ode=20
> base; compile-time performance is often tricky.

My big project is a compiler framework. It starts with a logic unification =
engine and that feeds into a bunch of big templates which compose together.=
 It's hairy, but compilation times have been going down over the few years =
of its existence, because GCC and Clang have improved faster than its compl=
exity has increased. (This is true even without hardware upgrades.) The tes=
tbed is a full-featured C++ preprocessor, and it compiles in 6-7 seconds in=
 Clang, and about 20 in GCC. It does have some bloat issues, weighing in at=
 a over a megabyte.

That's pretty fast. I have no complaints about metaprocessing performance p=
er se. I'd like to see bloat addressed better, such as being able to strip =
type_info::name strings, as I've mentioned in another thread, and better ov=
erall reporting on object code size. Compile time improvement would be a se=
condary gain.

> [1]: http://imgur.com/UoQZ7xd
> [2]: https://github.com/ldionne/hana-cppcon-2014/tree/gh-pages/code/bench=
mark/elem

I don't know this preprocessor, but the program looks vaguely like overload=
 set metaprogramming.

Yes, overload sets are the ideal tool for associative maps and they don't g=
et enough credit in contemporary literature.

Lack of widespread awareness of the basic techniques is one reason I think =
it's premature to redesign core features around a particular metaprocessing=
 paradigm.

--=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=_C75A69A2-499F-4C9C-96B7-290797512947
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;09&ndash;16, at 8:35 PM, Louis Dionne &lt;<a href=3D"mailto:ldionne.2=
@gmail.com">ldionne.2@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>&gt; Index=
ing the argument type-list of an uninstantiated specialization requires&nbs=
p;</div><div>&gt; walking up to the index, which is O(N).</div><div><br></d=
iv><div>This way of seeing things is naive. Extensive benchmarking shows th=
at the&nbsp;</div><div>mere counting of instantiations is not always the be=
st metric to measure&nbsp;</div><div>the compile-time performance of an alg=
orithm. For example, see this [1]</div><div>benchmark of a `is_one_of` meta=
function and the associated implementations[2].</div><div>All those curves =
have a O(N) behavior for the number of instantiations, but</div><div>clearl=
y this does not seem to matter for the compilation time.</div></div></block=
quote><div><br></div><div>In my experience, performance tends to be roughly=
 proportional to compiler memory use, and that is proportional to the total=
 number of data structures you ask for. Your instantiations are not equal t=
here because some require larger argument lists. Overload resolution takes =
time, too, even without SFINAE.</div><div><br></div><div>Anyway, all big-O =
notation is naive, it kind of goes without saying :P .</div><br><blockquote=
 type=3D"cite"><div dir=3D"ltr"><div>Also, it is possible to index a tuple =
without "walking up to the index"</div><div>(at least in a recursive manner=
); see [3].</div></div></blockquote><div><br></div><div>Fair nuff, and good=
 idea.</div><div><br></div><div><font face=3D"Courier">make_index_sequence<=
/font> still needs to &ldquo;walk&rdquo; unless it&rsquo;s an intrinsic. Ho=
wever, in any case, its result can be memoized.</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr"><div>The code in [3] is the kind of thing I was =
calling a "dirty trick". You are&nbsp;</div><div>right, a compiler intrinsi=
c for that would be desirable. </div></div></blockquote><div><br></div><div=
>I don&rsquo;t see that as being too dirty either. Anyway, my point is that=
 the current core language spec doesn&rsquo;t create a performance bottlene=
ck with pack manipulation, so we likely can&rsquo;t expect performance impr=
ovements, and any argument on that basis needs empirical evidence.</div><br=
><blockquote type=3D"cite"><div dir=3D"ltr"><div>Regarding the overall</div=
><div>cost of metaprograms, I think it would be worthwile to benchmark a re=
al code&nbsp;</div><div>base; compile-time performance is often tricky.</di=
v></div></blockquote><div><br></div><div>My big project is a compiler frame=
work. It starts with a logic unification engine and that feeds into a bunch=
 of big templates which compose together. It&rsquo;s hairy, but compilation=
 times have been going <i>down</i>&nbsp;over the few years of its existence=
, because GCC and Clang have improved faster than its complexity has increa=
sed. (This is true even without hardware upgrades.) The testbed is a full-f=
eatured C++ preprocessor, and it compiles in 6-7 seconds in Clang, and abou=
t 20 in GCC. It does have some bloat issues, weighing in at a over a megaby=
te.</div><div><br></div><div>That&rsquo;s pretty fast. I have no complaints=
 about metaprocessing performance per se. I&rsquo;d like to see bloat addre=
ssed better, such as being able to strip <font face=3D"Courier">type_info::=
name</font> strings, as I&rsquo;ve mentioned in another thread, and better =
overall reporting on object code size. Compile time improvement would be a =
secondary gain.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>[1=
]: <a href=3D"http://imgur.com/UoQZ7xd">http://imgur.com/UoQZ7xd</a></div><=
div>[2]: <a href=3D"https://github.com/ldionne/hana-cppcon-2014/tree/gh-pag=
es/code/benchmark/elem">https://github.com/ldionne/hana-cppcon-2014/tree/gh=
-pages/code/benchmark/elem</a></div></div></blockquote><div><br></div><div>=
I don&rsquo;t know this preprocessor, but the program looks vaguely like ov=
erload set metaprogramming.</div><div><br></div><div>Yes, overload sets are=
 the ideal tool for associative maps and they don&rsquo;t get enough credit=
 in contemporary literature.</div></div><br><div>Lack of widespread awarene=
ss of the basic techniques is one reason I think it&rsquo;s premature to re=
design core features around a particular metaprocessing paradigm.</div><div=
><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&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 />

--Apple-Mail=_C75A69A2-499F-4C9C-96B7-290797512947--

.

This is a multi-part message in MIME format.
--------------020806030009030701030509
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/16/2014 07:48 AM, Sean Middleditch wrote:
> On Monday, September 15, 2014 7:43:02 PM UTC-7, David Krauss wrote:
>
>     In my experience, a very significant proportion of type-lists
>     requiring metaprocessing are also instantiated as runtime tuples.
>
>
> A part of me is definitely thinking this may be better off as a set of
> extensions to std::tuple to just make it easier to use as a type list.
> All of the important operations either are already supposed (just in
> an IMHO overly-verbose manner) or can be added as a pure library
> extension, with compiler intrinsics for implementations that want to
> win compilation benchmarks. :)
>
> Another part of me is considering one of the use cases that Richard
> Smith presented in his feedback to N3761 that I completely left out of
> this draft paper: applying the indexing operation to a parameter pack
> expandion, e.g.:
>
>   template <typename... Ts>
>   void foo(Ts&&... argv) {
>     bar(argv)...[2];
>   };
>
>   // this line
>   foo<A, B, C>(a, b, c);
>
>   // essentially expands into this line
>   bar(c);
>
> Reading George's paper, I do believe that is also supported by ATPP.
> His paper would make type_at<> become:
>
>   template<std::size_t N, typename... T{}[N < sizeof...(T)]>
>   struct type_at {
>     using type = T{N};
>   };
>
> with no extra boilerplate needed, if I'm understanding it properly.
> Additionally, it makes out-of-bounds accesses a SFINAE error which is
> something else the committee said they wanted over my original
> type_at<>. George's paper also illustrates other basic type list
> operations.
>
> I could nitpick his chosen syntax but not much else (that's a good thing).
>
Sorry for the delayed reply. It is a great pleasure read your analyses
in this thread and I will try to summarize some details on this based on
your last comment!

/First, you got the syntax _perfectly_ when it comes to a type_at
implementation and what it supports. /This SFINAE behavior is by design
and what you wrote is one of the less verbose variations of a type_at
implementation using annotated template parameter packs.

Starting from here, I will also reply to one of your previous emails
regarding syntax choices. What is important to understand is that the
chosen syntax with *{}[]*, was the one with the minimum amount of
enclosure identifiers required that would offer unambiguous parsing
semantics for handling integral constant expressions within a template
parameter list. It was a point to begin with given that there are cases
with non-type packs and array types that can cause clashes if [] was
used as the first annotator.

Admittedly, the proposal is complex because packs are complex: there are
even expert users that have trouble understanding the notion of
deducible context and when multiple parameter packs are allowed there in
valid C++11/C++14 code - but I digress. Let's get to the most general,
use in declaration:

/**
  * For every triple N,M,K of positive integral constant expressions
where [N,M)
  * is a valid interval match when sizeof...(T) is in [N,M) and pack is an
  * any-tuple of the first sizeof...(T)/K parameters. Equivalences apply
that
  * safely degenerate into regular non-annotated pack, reference can be
found at
  * https://github.com/irrequietus/atpp
  */
template<typename... T{N,M}[K]>
struct example {};

However, there are other ways I reserve the right to propose in the
final draft, some of which I am to present here. If *{}[] *is confusing,
a viable alternative for annotators, for people who like [] everywhere
_/*could*/_ be:

// #1 an alternative for stylistic nay-sayers I am working on
template<typename ...T:[N,M][K]>
struct example {};

// #2 another alternative for stylistic nay-sayers I am working on
template<typename ...T:(N,M)[K]>
struct example {};

// #3 another alternative for stylistic nay-sayers I am working on
template<typename ...T:[N:M][K]>
struct example {};

// #4 another alternative for stylistic nay-sayers I am working on
template<typename ...T:(N,M)[K]>
struct example {};

Yet again, another choice where colons are used immediately before as
well as within the first annotator. None of the rules about SFINAE,
ranged sizes, fixed sizes, individual and ranged access of types as well
as reflective uses on the pattern properties the pack may be having changes.

In the context of previous examples, it becomes evident that T:[X] or
T:(X) would be individual access of parameter at index X; for the time
being, ATPP is based on T{X} for that/because of the unambiguous parsing
within parameter lists when it comes to implementation during the
inception of the draft itself/. Do not be surprised if I include such
alternative syntaxes for the same things that my draft is about :).

/You see, I am interested in the internal mechanisms of how this should
work, not just how it should look./

The entire ATPP proposal is about not just pack processing, but also
about _/*generative*/_ properties that such pack semantics cover. The
latter do not clash with the EWG's (in)famous poster-child, known as
"concepts". After all, concepts in their interaction with parameter
packs do rely on the semantics of the triple-dot in declaration and
expansion and not the other way around. Therefore, expanding pack
semantics properly, only helps concepts into becoming something more
useful, instead of poor man's typeclasses that in the end only do
predicates (that e.g. SFINAE-based libraries can do a hell of a better
job with, including implementing compile time error *_/monads/_*_,_ as I
cite in the references).

I believe that extending parameter pack semantics by either doing just
fixed size pack shorthands or individual access separately is going to
cause us more trouble with the "small individual change" approach over a
cohere solution. The solutions I have seen so far result in the following:

 1. more boilerplate for simple things (/vertical and horizontal
    expansion problems, known by _preprocessor metaprogrammers_/)
 2. more recursive instantiations for simple things making things
    combinatorially more difficult as well as more costly for the
    compiler (each template instantiation has a resource cost during
    compilation).
 3. constexpr overloads for non-type parameter manipulation for some
    stdlib algorithms that do not address the issue of type and template
    type parameter packs, let alone it increases the need for recursive
    instantiations if those are especially involved.
 4. Abuses of std::tuple still have complex internal mechanics that rely
    on increasingly complex recursive instantiations, which are the nail
    in the coffin for what EWG#30 is concerned.
 5. depend on the kindness of strangers (compiler intrinsics can yield
    unexpected non-benefits and do not avoid the boilerplate problem, or
    preprocessor stunts being required for libraries implementing such
    features)

By design, /_*ATPP is immune to all of them*_/ and can be made even more
explicitly so. The syntax is so terse and unobtrussive, that does not
break existing code. In the following updates to ATPP prior to my
requesting a number from Ville in relation to EWG#30, you will also find
the proposed solution for the multiple parameter pack problem and
context deducibility, without additional syntax involved or breaking
changes.

My only purpose by getting into this was to offer a technically complete
solution to the EWG in relation to issues like EWG#30. They seem to be
interested in this as a language feature as by written record for at
least 2 years now. My first hand experience with the EWG however was that:

 1. not all of them have the ideas clear on this matter, top brass
    included (giving self-conflicting guidelines).
 2. more of them are very much afraid of C++ template meta-programming
    for personal reasons.
 3. most of them do not see that disjoint approaches on packs lead to
    increased boilerplate and counterproductive syntactical acrobatics.
 4. some of them are not primarily concerned about actual technical issues.
 5. a few of them would prefer "sponsoring" the same idea if it was
    "tossed" and worked upon by one of their own choosing.

Regardless, a versatile,/horrifically lovecraftian/ language like C++
merits to have a paper trail of a complete and cohere solution to its
parameter pack problems. We are not just playing with parameter access
here, we are actually ending up playing with function template overloads
and class template partial specialization semantics.

I will be quite satisfied to provide a concrete solution or even work
with any coauthor who wishes to pursue this. Considerable portions of
libraries like boost::mpl would become obsolete for doing really
practical, as well as quite performant, stuff with parameter packs. The
paper trail of it (and its background) will exist for anybody wishing to
consult it and construct upon a _*/solid/*_ technical basis.

These past few months I have been working on simplifying everything a
lot. Some of this work is already public on the git repository for this
draft. Planning for such a language feature, is a win/win for
technically sound C++ over self-conflicting socially backed up
pontifications.

Thanks for taking the time to examine ATPP,

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/.

--------------020806030009030701030509
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">
    <br>
    <div class=3D"moz-cite-prefix">On 09/16/2014 07:48 AM, Sean
      Middleditch wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:2d9c7a5a-1f31-416c-b9ee-293e88d87b0f@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Monday, September 15, 2014 7:43:02 PM UTC-7,
        David Krauss wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div style=3D"word-wrap:break-word">
            <div>
              <div>In my experience, a very significant proportion of
                type-lists requiring metaprocessing are also
                instantiated as runtime tuples.<br>
              </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>A part of me is definitely thinking this may be better off
          as a set of extensions to std::tuple to just make it easier to
          use as a type list. All of the important operations either are
          already supposed (just in an IMHO overly-verbose manner) or
          can be added as a pure library extension, with compiler
          intrinsics for implementations that want to win compilation
          benchmarks. :)</div>
        <div><br>
        </div>
        <div>Another part of me is considering one of the use cases that
          Richard Smith presented in his feedback to N3761 that I
          completely left out of this draft paper: applying the indexing
          operation to a parameter pack expandion, e.g.:</div>
        <div><br>
        </div>
        <div>=C2=A0 template &lt;typename... Ts&gt;</div>
        <div>=C2=A0 void foo(Ts&amp;&amp;... argv) {</div>
        <div>=C2=A0 =C2=A0 bar(argv)...[2];</div>
        <div>=C2=A0 };</div>
        <div><br>
        </div>
        <div>=C2=A0 // this line</div>
        <div>=C2=A0 foo&lt;A, B, C&gt;(a, b, c);</div>
        <div><br>
        </div>
        <div>=C2=A0 // essentially expands into this line</div>
        <div>=C2=A0 bar(c);</div>
        <div><br>
        </div>
        <div>Reading George's paper, I do believe that is also supported
          by ATPP. His paper would make type_at&lt;&gt; become:</div>
        <div><br>
        </div>
        <div>=C2=A0 template&lt;std::size_t N, typename... T{}[N &lt;
          sizeof...(T)]&gt;<br>
        </div>
        <div>
          <div>=C2=A0 struct type_at {</div>
          <div>=C2=A0 =C2=A0 using type =3D T{N};</div>
          <div>=C2=A0 };</div>
        </div>
        <div><br>
        </div>
        <div>with no extra boilerplate needed, if I'm understanding it
          properly. Additionally, it makes out-of-bounds accesses a
          SFINAE error which is something else the committee said they
          wanted over my original type_at&lt;&gt;. George's paper also
          illustrates other basic type list operations.</div>
        <div><br>
        </div>
        <div>I could nitpick his chosen syntax but not much else (that's
          a good thing).</div>
      </div>
      <br>
    </blockquote>
    Sorry for the delayed reply. It is a great pleasure read your
    analyses in this thread and I will try to summarize some details on
    this based on your last comment!<br>
    <br>
    <i>First, you got the syntax <u>perfectly</u> when it comes to a
      type_at implementation and what it supports. </i>This SFINAE
    behavior is by design and what you wrote is one of the less verbose
    variations of a type_at implementation using annotated template
    parameter packs.<br>
    <br>
    Starting from here, I will also reply to one of your previous emails
    regarding syntax choices. What is important to understand is that
    the chosen syntax with <b>{}[]</b>, was the one with the minimum
    amount of enclosure identifiers required that would offer
    unambiguous parsing semantics for handling integral constant
    expressions within a template parameter list. It was a point to
    begin with given that there are cases with non-type packs and array
    types that can cause clashes if [] was used as the first annotator.<br>
    <br>
    Admittedly, the proposal is complex because packs are complex: there
    are even expert users that have trouble understanding the notion of
    deducible context and when multiple parameter packs are allowed
    there in valid C++11/C++14 code - but I digress. Let's get to the
    most general, use in declaration:<br>
    <br>
    /**<br>
    =C2=A0* For every triple N,M,K of positive integral constant expression=
s
    where [N,M)<br>
    =C2=A0* is a valid interval match when sizeof...(T) is in [N,M) and pac=
k
    is an<br>
    =C2=A0* any-tuple of the first sizeof...(T)/K parameters. Equivalences
    apply that<br>
    =C2=A0* safely degenerate into regular non-annotated pack, reference ca=
n
    be found at<br>
    =C2=A0* <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/i=
rrequietus/atpp">https://github.com/irrequietus/atpp</a><br>
    =C2=A0*/<br>
    template&lt;typename... T{N,M}[K]&gt;<br>
    struct example {};<br>
    <br>
    However, there are other ways I reserve the right to propose in the
    final draft, some of which I am to present here. If <b>{}[] </b>is
    confusing, a viable alternative for annotators, for people who like
    [] everywhere <font color=3D"#ff0000"><u><i><b>could</b></i></u></font>
    be:<br>
    <br>
    // #1 an alternative for stylistic nay-sayers I am working on<br>
    template&lt;typename ...T:[N,M][K]&gt;<br>
    struct example {};<br>
    <br>
    // #2 another alternative for stylistic nay-sayers I am working on<br>
    template&lt;typename ...T:(N,M)[K]&gt;<br>
    struct example {};<br>
    <br>
    // #3 another alternative for stylistic nay-sayers I am working on<br>
    template&lt;typename ...T:[N:M][K]&gt;<br>
    struct example {};<br>
    <br>
    // #4 another alternative for stylistic nay-sayers I am working on<br>
    template&lt;typename ...T:(N,M)[K]&gt;<br>
    struct example {};<br>
    <br>
    Yet again, another choice where colons are used immediately before
    as well as within the first annotator. None of the rules about
    SFINAE, ranged sizes, fixed sizes, individual and ranged access of
    types as well as reflective uses on the pattern properties the pack
    may be having changes.<br>
    <br>
    In the context of previous examples, it becomes evident that T:[X]
    or T:(X) would be individual access of parameter at index X; for the
    time being, ATPP is based on T{X} for that<i> because of the
      unambiguous parsing within parameter lists when it comes to
      implementation during the inception of the draft itself</i>. Do
    not be surprised if I include such alternative syntaxes for the same
    things that my draft is about :).<br>
    <br>
    <i>You see, I am interested in the internal mechanisms of how this
      should work, not just how it should look.</i><br>
    <br>
    The entire ATPP proposal is about not just pack processing, but also
    about <u><i><b>generative</b></i></u> properties that such pack
    semantics cover. The latter do not clash with the EWG's (in)famous
    poster-child, known as "concepts". After all, concepts in their
    interaction with parameter packs do rely on the semantics of the
    triple-dot in declaration and expansion and not the other way
    around. Therefore, expanding pack semantics properly, only helps
    concepts into becoming something more useful, instead of poor man's
    typeclasses that in the end only do predicates (that e.g.
    SFINAE-based libraries can do a hell of a better job with, including
    implementing compile time error <b><u><i>monads</i></u></b><u>,</u>
    as I cite in the references).<br>
    <br>
    I believe that extending parameter pack semantics by either doing
    just fixed size pack shorthands or individual access separately is
    going to cause us more trouble with the "small individual change"
    approach over a cohere solution. The solutions I have seen so far
    result in the following:<br>
    <ol>
      <li>more boilerplate for simple things (<i>vertical and horizontal
          expansion problems, known by <u>preprocessor metaprogrammers</u><=
/i>)</li>
      <li>more recursive instantiations for simple things making things
        combinatorially more difficult as well as more costly for the
        compiler (each template instantiation has a resource cost during
        compilation).</li>
      <li>constexpr overloads for non-type parameter manipulation for
        some stdlib algorithms that do not address the issue of type and
        template type parameter packs, let alone it increases the need
        for recursive instantiations if those are especially involved.</li>
      <li>Abuses of std::tuple still have complex internal mechanics
        that rely on increasingly complex recursive instantiations,
        which are the nail in the coffin for what EWG#30 is concerned.<br>
      </li>
      <li>depend on the kindness of strangers (compiler intrinsics can
        yield unexpected non-benefits and do not avoid the boilerplate
        problem, or preprocessor stunts being required for libraries
        implementing such features)<br>
      </li>
    </ol>
    By design, <i><font color=3D"#ff0000"><u><b>ATPP is immune to all of
            them</b></u></font></i> and can be made even more explicitly
    so. The syntax is so terse and unobtrussive, that does not break
    existing code. In the following updates to ATPP prior to my
    requesting a number from Ville in relation to EWG#30, you will also
    find the proposed solution for the multiple parameter pack problem
    and context deducibility, without additional syntax involved or
    breaking changes.<br>
    <br>
    My only purpose by getting into this was to offer a technically
    complete solution to the EWG in relation to issues like EWG#30. They
    seem to be interested in this as a language feature as by written
    record for at least 2 years now. My first hand experience with the
    EWG however was that:<br>
    <ol>
      <li>not all of them have the ideas clear on this matter, top brass
        included (giving self-conflicting guidelines).<br>
      </li>
      <li>more of them are very much afraid of C++ template
        meta-programming for personal reasons.<br>
      </li>
      <li>most of them do not see that disjoint approaches on packs lead
        to increased boilerplate and counterproductive syntactical
        acrobatics.</li>
      <li>some of them are not primarily concerned about actual
        technical issues.</li>
      <li>a few of them would prefer "sponsoring" the same idea if it
        was "tossed" and worked upon by one of their own choosing.</li>
    </ol>
    Regardless, a versatile,<i> horrifically lovecraftian</i> language
    like C++ merits to have a paper trail of a complete and cohere
    solution to its parameter pack problems. We are not just playing
    with parameter access here, we are actually ending up playing with
    function template overloads and class template partial
    specialization semantics.<br>
    <br>
    I will be quite satisfied to provide a concrete solution or even
    work with any coauthor who wishes to pursue this. Considerable
    portions of libraries like boost::mpl would become obsolete for
    doing really practical, as well as quite performant, stuff with
    parameter packs. The paper trail of it (and its background) will
    exist for anybody wishing to consult it and construct upon a <u><b><i>s=
olid</i></b></u>
    technical basis.<br>
    <br>
    These past few months I have been working on simplifying everything
    a lot. Some of this work is already public on the git repository for
    this draft. Planning for such a language feature, is a win/win for
    technically sound C++ over self-conflicting socially backed up
    pontifications.<br>
    <br>
    Thanks for taking the time to examine ATPP,<br>
    <br>
    George<br>
    <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&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 />

--------------020806030009030701030509--

.

This is a multi-part message in MIME format.
--------------050602080407020403060604
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/16/2014 04:12 AM, Louis Dionne wrote:
> On Monday, 15 September 2014 16:29:08 UTC-4, Sean Middleditch wrote:
>
> [...]
>
> > I think you can take a bit of a tricky approach here, though. You can
> > provide a library-like interface that is intended to be backed by
> > compiler intrinsics. The sales pitch can be "here's a pure-library
> > implementation, but if you replace this and that bits in the
> > implementation with intrinsics, you get a huge performance advantage."
>
> [...]
>
> Based on the experience of writing Boost.Hana, my opinion is that we
> do not
> want a better support for parameter packs, at least not "officially".
> Let me
> explain.
>

Based on my own experience of writing several different libraries like
boost::mpl, boost::hana and boost::preprocessor, doing recursive
instantiations for trivial pack processing or relying on muddy compiler
intrinsics for efficient compile-time big-O results is something that is
going to bite you back in the end. So, we need _/official/_ support. And
isn't EWG#30 active for 2+ years just for this?

> Parameter packs do not compose very well because they are not a single
> entity,
> and they are bound to express something isomorphic (via hand waving) to
> std::tuple. However, there are several other data structures that are
> useful
> when metaprogramming. For example, one could imagine a tree containing
> heterogeneous objects, which could be useful for expression templates.
>

Parameter packs do not compose very well because they are second-class
citizens in a template parameter list, where anything practical has to
be done through recursive template instantiations, including something
as trivial as index/range-based access.

Do notice that C++ triple-dot expansion offers insight into even really
naive implementations of structure preserving transformations (naively
alla Haskell fmap):

// a "function"
*template*<*typename*>
*class*  funny {};

// an "enclosure" because we need to wrap the pack
*template*<*typename*...>
*class*  enclosure {};

// fmap implemented naively, for didactic purposes
*template*<*template*<*typename*...>*class*  F
         ,*typename*... X >
*struct*  fmap {
   *template*<*template*<*typename*...>*class*  Enclosure_T>
   *using*  apply
       = Enclosure_T<F<X>...>;  // fmap is actually the triple-dot!
};


*typedef*  *typename*  fmap<funny,int,char,long>::*template*  apply<enclosure> fmap_applied;


This aspect of the triple-dot is even exploited by concepts in order to
work with parameter packs. And yet, we have to resort into recursive
template instantiations for even accessing an individual parameter.
Worse, /we cannot even do structure-preserving transformations over a
range of indexes/ /within the pack without using recursive template
instantiations/. We should only use such recursive instantiations when
meaningful catamorphisms are in play, not for accessing a parameter or a
range of parameters within known indices! To cite Shakespeare in good
will, "something is rotten in the state of Denmark".

Now for the expression templates you cite. A posteriori, most people
involved in expression template meta-programming and had EWG access,
were not fully aware of the issues they created when language level type
inference based on 'auto' did not account for expression templates. Same
goes with something a lot more complicated in its simplicity: parameter
packs. Only that the mess that can be created this time is far worse.

As for compile time data structures, instead of the example of a tree,
why stop there? Libraries doing meta-programming should provide compile
time _/graphs/_ and algorithms for them instead of having laborious,
compiler-intrinsic dependent code for implementing boost::mpl::vector,
boost::mpl::map and their like "efficiently". This would practically let
you write your own AST-based language through C++TMP more easily and in
a formally correct manner, while making use of the inlining features of
a C++ compiler. I have no doubt that such a feature will become
available in libraries like boost::mpl at some point, or their successors.

But for such powerful data structures as compile-time graphs to not have
really hideous performance during deployment, one needs to get packs
right. Right now, they are crippled for any practical use besides
shorthand for variadics in toto.

> That being said, a valid objection would be the compile-time
> performance of
> std::tuple, which is really bad. I think this is a problem in itself
> and it
> ought to be addressed, but not by introducing a new construct that would
> address this issue only. If you look at Hana's implementation, the dirty
> tricks are very rare [1], and it would be easy to handle some of these
> with
> compiler-dependent intrinsics.

The compile time performance of the std::tuple class template and its
accompanying std::get function template are shameful /because of the way
they are forced to be implemented due to the lack of language features
as those required by EWG#30 resolution/. Even having individual
parameter access, would make them trivial enough to not be even a
concern during "compile-time". The more you go down the recursive
instantiation and compiler intrinsic path for these things, the less you
are going to be able to have predictable performance between different
compilers - or even uniform behavior. That's why you need this at a
standard level. See my reply to Sean on this.

>
> TL;DR
> For what it's worth, I would favor a well-thought library approach with
> (possibly) a compiler-backed implementation more than a change to the
> core language.
>
>
Sean said Stroustrup himself deliberated on the computational
complexities involved even for individual parameter access in a pack
through a library over a language feature. Given the status of EWG#30, I
seriously see no reason to not have fundamental pack manipulation as a
language feature over any other solution. Especially if it would allow
us to not require a third-party, unpredictably portable library
regardless of how good it actually is. Wasn't that one of the reasons
parameter packs got variadic semantics in the end, to begin with?

Regards,

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/.

--------------050602080407020403060604
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">
    <br>
    <div class=3D"moz-cite-prefix">On 09/16/2014 04:12 AM, Louis Dionne
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:921715a7-2cf7-45e1-9764-cae5d5aeceec@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>On Monday, 15 September 2014 16:29:08 UTC-4, Sean
            Middleditch wrote:</div>
          <div><br>
          </div>
          <div>[...]</div>
          <div><br>
          </div>
          <div>&gt; I think you can take a bit of a tricky approach
            here, though. You can=C2=A0</div>
          <div>&gt; provide a library-like interface that is intended to
            be backed by=C2=A0</div>
          <div>&gt; compiler intrinsics. The sales pitch can be "here's
            a pure-library=C2=A0</div>
          <div>&gt; implementation, but if you replace this and that
            bits in the=C2=A0</div>
          <div>&gt; implementation with intrinsics, you get a huge
            performance advantage."=C2=A0</div>
          <div><br>
          </div>
          <div>[...]</div>
          <div><br>
          </div>
          <div>Based on the experience of writing Boost.Hana, my opinion
            is that we do not</div>
          <div>want a better support for parameter packs, at least not
            "officially". Let me</div>
          <div>explain.</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Based on my own experience of writing several different libraries
    like boost::mpl, boost::hana and boost::preprocessor, doing
    recursive instantiations for trivial pack processing or relying on
    muddy compiler intrinsics for efficient compile-time big-O results
    is something that is going to bite you back in the end. So, we need
    <u><i>official</i></u> support. And isn't EWG#30 active for 2+ years
    just for this?<br>
    <br>
    <blockquote
      cite=3D"mid:921715a7-2cf7-45e1-9764-cae5d5aeceec@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>Parameter packs do not compose very well because they are
            not a single entity,</div>
          <div>and they are bound to express something isomorphic (via
            hand waving) to</div>
          <div>std::tuple. However, there are several other data
            structures that are useful</div>
          <div>when metaprogramming. For example, one could imagine a
            tree containing=C2=A0</div>
          <div>heterogeneous objects, which could be useful for
            expression templates.</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Parameter packs do not compose very well because they are
    second-class citizens in a template parameter list, where anything
    practical has to be done through recursive template instantiations,
    including something as trivial as index/range-based access.<br>
    <br>
    Do notice that C++ triple-dot expansion offers insight into even
    really naive implementations of structure preserving transformations
    (naively alla Haskell fmap):<br>
    <br>
    <pre style=3D"color:#1f1c1b;background-color:#ffffff;"><span style=3D"c=
olor:#898887;">// a "function"</span>
<b>template</b>&lt;<b>typename</b>&gt;
<b>class</b> funny {};

<span style=3D"color:#898887;">// an "enclosure" because we need to wrap th=
e pack</span>
<b>template</b>&lt;<b>typename</b>...&gt;
<b>class</b> enclosure {};

<span style=3D"color:#898887;">// fmap implemented naively, for didactic pu=
rposes</span>
<b>template</b>&lt; <b>template</b>&lt;<b>typename</b>...&gt; <b>class</b> =
F
        , <b>typename</b>... X &gt;
<b>struct</b> fmap {
  <b>template</b>&lt;<b>template</b>&lt;<b>typename</b>...&gt; <b>class</b>=
 Enclosure_T&gt;
  <b>using</b> apply
      =3D Enclosure_T&lt;F&lt;X&gt;...&gt;;<span style=3D"color:#898887;"> =
// fmap is actually the triple-dot!</span>
};


<b>typedef</b> <b>typename</b> fmap&lt;funny,<span style=3D"color:#0057ae;"=
>int</span>,<span style=3D"color:#0057ae;">char</span>,<span style=3D"color=
:#0057ae;">long</span>&gt;::<b>template</b> apply&lt;enclosure&gt; fmap_app=
lied;
</pre>
    <br>
    This aspect of the triple-dot is even exploited by concepts in order
    to work with parameter packs. And yet, we have to resort into
    recursive template instantiations for even accessing an individual
    parameter. Worse, <i>we cannot even do structure-preserving
      transformations over a range of indexes</i> <i>within the pack
      without using recursive template instantiations</i>. We should
    only use such recursive instantiations when meaningful catamorphisms
    are in play, not for accessing a parameter or a range of parameters
    within known indices! To cite Shakespeare in good will, "something
    is rotten in the state of Denmark".<br>
    <br>
    Now for the expression templates you cite. A posteriori, most people
    involved in expression template meta-programming and had EWG access,
    were not fully aware of the issues they created when language level
    type inference based on 'auto' did not account for expression
    templates. Same goes with something a lot more complicated in its
    simplicity: parameter packs. Only that the mess that can be created
    this time is far worse.<br>
    <br>
    As for compile time data structures, instead of the example of a
    tree, why stop there? Libraries doing meta-programming should
    provide compile time <u><i>graphs</i></u> and algorithms for them
    instead of having laborious, compiler-intrinsic dependent code for
    implementing boost::mpl::vector, boost::mpl::map and their like
    "efficiently". This would practically let you write your own
    AST-based language through C++TMP more easily and in a formally
    correct manner, while making use of the inlining features of a C++
    compiler. I have no doubt that such a feature will become available
    in libraries like boost::mpl at some point, or their successors.<br>
    <br>
    But for such powerful data structures as compile-time graphs to not
    have really hideous performance during deployment, one needs to get
    packs right. Right now, they are crippled for any practical use
    besides shorthand for variadics in toto.<br>
    <br>
    <blockquote
      cite=3D"mid:921715a7-2cf7-45e1-9764-cae5d5aeceec@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>That being said, a valid objection would be the
            compile-time performance of</div>
          <div>std::tuple, which is really bad. I think this is a
            problem in itself and it</div>
          <div>ought to be addressed, but not by introducing a new
            construct that would=C2=A0</div>
          <div>address this issue only. If you look at Hana's
            implementation, the dirty=C2=A0</div>
          <div>tricks are very rare [1], and it would be easy to handle
            some of these with=C2=A0</div>
          <div>compiler-dependent intrinsics.</div>
        </div>
      </div>
    </blockquote>
    <br>
    The compile time performance of the std::tuple class template and
    its accompanying std::get function template are shameful <i>because
      of the way they are forced to be implemented due to the lack of
      language features as those required by EWG#30 resolution</i>. Even
    having individual parameter access, would make them trivial enough
    to not be even a concern during "compile-time". The more you go down
    the recursive instantiation and compiler intrinsic path for these
    things, the less you are going to be able to have predictable
    performance between different compilers - or even uniform behavior.
    That's why you need this at a standard level. See my reply to Sean
    on this.<br>
    <br>
    <blockquote
      cite=3D"mid:921715a7-2cf7-45e1-9764-cae5d5aeceec@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div><br>
          </div>
          <div>TL;DR=C2=A0</div>
          <div>For what it's worth, I would favor a well-thought library
            approach with</div>
          <div>(possibly) a compiler-backed implementation more than a
            change to the=C2=A0</div>
          <div>core language.</div>
          <div><br>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    Sean said Stroustrup himself deliberated on the computational
    complexities involved even for individual parameter access in a pack
    through a library over a language feature. Given the status of
    EWG#30, I seriously see no reason to not have fundamental pack
    manipulation as a language feature over any other solution.
    Especially if it would allow us to not require a third-party,
    unpredictably portable library regardless of how good it actually
    is. Wasn't that one of the reasons parameter packs got variadic
    semantics in the end, to begin with?<br>
    <br>
    Regards,<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&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 />

--------------050602080407020403060604--

.

On 09/15/2014 11:29 PM, Sean Middleditch wrote:
> On Mon, Sep 15, 2014 at 12:52 PM, George Makrydakis
> <irrequietus@gmail.com> wrote:
>> On 09/15/2014 10:36 PM, Sean Middleditch wrote:
>>
>> Honestly, the reason I originally proposed type_at<> and not a language
>> change was that I was reasonably certain they'd prefer a library approach!
>> :) It's definitely clear that a range needs to be supported as well as just
>> a singular index, which if nothing else is something I'll add to my paper
>> (assuming I bother to submit it; sounds like you have this covered).
>>
>> Thanks for replying! I think that library approaches are slightly
>> inappropriate when it comes to parameter pack access because they only lead
>> us into more recursive template instantiations. But I see the strategy
>> there!
> I think you can take a bit of a tricky approach here, though. You can
> provide a library-like interface that is intended to be backed by
> compiler intrinsics. The sales pitch can be "here's a pure-library
> implementation, but if you replace this and that bits in the
> implementation with intrinsics, you get a huge performance advantage."
>
> I half suspect that to be the reply to the ...[N] syntax and even
> considered just tossing it in the first version as an alternative.
>
> I think there may be some advantages to users, too. Considering your
> ...T{N,M}[K] syntax for instance, that's just really obtuse and hard
> to read to me. It's not clear which number is what. A library approach
> could be a bit clearer and a high-quality implementation could rely on
> intrinsics to have roughly identical performance.
>
> e.g. std::type_at<> could have the inefficient but working
> implementation I originally proposed in N3761 but then also clearly
> state that high-quality implementation would likely be implemented as:
>
> template <size_t N, typename ...R>
> using type_at = __compiler_intrinic<N, R...>;
>
> and likewise for value_at and some type list slice/concat operations.
>
> 100% library code that could even be cut-n-paste out of the paper into
> an implementation that's trying to bootstrap into C++1z conformance
> but for which "real" compilers can optimize away into
> language-semantic speeds.
>
>> turing completeness in its ad-hoc parametric polymorphism (templates). But
>> both syntax and semantics can be very tricky and the "little additions"
>> approach favored by some is only going to lead us to fragmented or
>> increasingly context-dependent syntax that will break under its own weight.
> I agree. This is also another advantage of preferring the library
> veneer API rather than core language changes. It has less impact on
> long-term evolution.
>
Replied in one of your following emails comprehensively on this!

Regards,

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/.

.

This is a multi-part message in MIME format.
--------------060305060401000800000709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/16/2014 05:42 AM, David Krauss wrote:
>
> On 2014-09-16, at 9:12 AM, Louis Dionne <ldionne.2@gmail.com
> <mailto:ldionne.2@gmail.com>> wrote:
>
>> That being said, a valid objection would be the compile-time
>> performance of
>> std::tuple, which is really bad.
>
> Wrapping a pack as a tuple type, i.e. merely naming std::tuple< T ...
> >, is essentially zero work for the compiler.
>
>
Only that it is not once you have to instantiate several /_*different
*_/copies of std:tuple<T...> for each time you wish to manipulate the
contents of T... into an X..., or access the results of such
manipulation. Regardless of what approach you take through a library, it
is always penalized compile-time performance-wise for practical
constructs over a language feature, which is the soul of what EWG#30 is
currently all about.

Regards,

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/.

--------------060305060401000800000709
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/16/2014 05:42 AM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:E021F21E-A607-444B-9203-02C1C8C51DF6@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On 2014&ndash;09&ndash;16, at 9:12 AM, Louis Dionne &lt;<a
            moz-do-not-send="true" href="mailto:ldionne.2@gmail.com">ldionne.2@gmail.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div dir="ltr">
            <div>
              <div>That being said, a valid objection would be the
                compile-time performance of</div>
              <div>std::tuple, which is really bad. </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>Wrapping a pack as a tuple type, i.e. merely naming <font
            face="Courier">std::tuple&lt; T ... &gt;</font>, is
          essentially zero work for the compiler.</div>
        <div><br>
        </div>
        <br>
      </div>
    </blockquote>
    Only that it is not once you have to instantiate several <i><u><b>different
        </b></u></i>copies of std:tuple&lt;T...&gt; for each time you
    wish to manipulate the contents of T... into an X..., or access the
    results of such manipulation. Regardless of what approach you take
    through a library, it is always penalized compile-time
    performance-wise for practical constructs over a language feature,
    which is the soul of what EWG#30 is currently all about.<br>
    <br>
    Regards,<br>
    <br>
    George<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&quot; 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 />

--------------060305060401000800000709--

.

This is a multi-part message in MIME format.
--------------040706050607090106000601
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/17/2014 05:43 PM, George Makrydakis wrote:
>
> However, there are other ways I reserve the right to propose in the
> final draft, some of which I am to present here. If *{}[] *is
> confusing, a viable alternative for annotators, for people who like []
> everywhere _/*could*/_ be:
>
> // #1 an alternative for stylistic nay-sayers I am working on
> template<typename ...T:[N,M][K]>
> struct example {};
>
> // #2 another alternative for stylistic nay-sayers I am working on
> template<typename ...T:(N,M)[K]>
> struct example {};
>
> // #3 another alternative for stylistic nay-sayers I am working on
> template<typename ...T:[N:M][K]>
> struct example {};
>
> // #4 another alternative for stylistic nay-sayers I am working on
> template<typename ...T:(N,M)[K]>
> struct example {};
>
>

A copy error for the alternative (not in draft or final, see the : over
the comma) :

template<typename ...T:(N:K)[K]>
struct example{};

Regards,

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/.

--------------040706050607090106000601
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 09/17/2014 05:43 PM, George
      Makrydakis wrote:<br>
    </div>
    <blockquote cite="mid:54199E01.7070502@gmail.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <br>
      However, there are other ways I reserve the right to propose in
      the final draft, some of which I am to present here. If <b>{}[] </b>is

      confusing, a viable alternative for annotators, for people who
      like [] everywhere <font color="#ff0000"><u><i><b>could</b></i></u></font>
      be:<br>
      <br>
      // #1 an alternative for stylistic nay-sayers I am working on<br>
      template&lt;typename ...T:[N,M][K]&gt;<br>
      struct example {};<br>
      <br>
      // #2 another alternative for stylistic nay-sayers I am working on<br>
      template&lt;typename ...T:(N,M)[K]&gt;<br>
      struct example {};<br>
      <br>
      // #3 another alternative for stylistic nay-sayers I am working on<br>
      template&lt;typename ...T:[N:M][K]&gt;<br>
      struct example {};<br>
      <br>
      // #4 another alternative for stylistic nay-sayers I am working on<br>
      template&lt;typename ...T:(N,M)[K]&gt;<br>
      struct example {};<br>
      <br>
      <br>
    </blockquote>
    <br>
    A copy error for the alternative (not in draft or final, see the :
    over the comma) :<br>
    <br>
    template&lt;typename ...T:(N:K)[K]&gt;<br>
    struct example{};<br>
    <br>
    Regards,<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&quot; 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 />

--------------040706050607090106000601--

.

On 17/09/2014 12:42 p.m., George Makrydakis wrote:
>
> On 09/16/2014 04:12 AM, Louis Dionne wrote:
>> That being said, a valid objection would be the compile-time
>> performance of
>> std::tuple, which is really bad. I think this is a problem in itself
>> and it
>> ought to be addressed, but not by introducing a new construct that would
>> address this issue only. If you look at Hana's implementation, the dirty
>> tricks are very rare [1], and it would be easy to handle some of these
>> with
>> compiler-dependent intrinsics.
>
> The compile time performance of the std::tuple class template and its
> accompanying std::get function template are shameful /because of the way
> they are forced to be implemented due to the lack of language features
> as those required by EWG#30 resolution/. Even having individual
> parameter access, would make them trivial enough to not be even a
> concern during "compile-time". The more you go down the recursive
> instantiation and compiler intrinsic path for these things, the less you
> are going to be able to have predictable performance between different
> compilers - or even uniform behavior. That's why you need this at a
> standard level.

That sounds like a wild claim, and I would appreciate if you would=20
expand on it a bit. After all, no single piece of `std::tuple` and=20
related facilities is /forced/ to be implemented via recursive template=20
instantiation. Furthermore, considering slow compile-times in heavily=20
templated code nowadays is a direct consequence of name mangling, there=20
would be hardly any benefit from using a language feature as opposed to=20
an efficient library implementation; the same amount of mangling would=20
be involved.

>> TL;DR
>> For what it's worth, I would favor a well-thought library approach with
>> (possibly) a compiler-backed implementation more than a change to the
>> core language.
>>
>>
> Sean said Stroustrup himself deliberated on the computational
> complexities involved even for individual parameter access in a pack
> through a library over a language feature. Given the status of EWG#30, I
> seriously see no reason to not have fundamental pack manipulation as a
> language feature over any other solution. Especially if it would allow
> us to not require a third-party, unpredictably portable library
> regardless of how good it actually is.

As time goes by, we know more and more ways of avoiding big recursive=20
template instantiations. I would like to say that anything that is not a=20
fold can be implemented without recursion, but that'd be a hard claim to=20
prove.

We also know more and more of what actually does cause compile-time=20
performance to drop. Yet, I am not aware of any active effort to avoid=20
or diminish the effect of name mangling in execution time and memory=20
usage during compilation.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=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=_BB392895-0923-4784-BB09-0DC5590D9FA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-17, at 11:48 PM, George Makrydakis <irrequietus@gmail.com> wrote=
:

>=20
> On 09/16/2014 05:42 AM, David Krauss wrote:
>>=20
>> Wrapping a pack as a tuple type, i.e. merely naming std::tuple< T ... >,=
 is essentially zero work for the compiler.
>>=20
> Only that it is not once you have to instantiate several different copies=
 of std:tuple<T...> for each time

You're not paying attention, and unfortunately your experience is out of da=
te.

A user should only incur a std::tuple instantiation when they actually need=
 it as a runtime container. Accidental instantiation is an error which requ=
ires fixing.

Even for a low-overhead, empty type, accidental instantiation still represe=
nts significant overhead compared to just having an uninstantiated template=
-id, which is similar to an incomplete class.

> you wish to manipulate the contents of T... into an X..., or access the r=
esults of such manipulation.

Certainly not. You could have had an argument that older standard library i=
mplementations would instantiate std::tuple inside std::tuple_element, but =
mapping tuple<...> =3D> T... =3D> F<T>... won't instantiate anything beside=
s F, and that's been true since C++11 (and C++98 variadic emulation by nest=
ed arguments... but that might not always have been an optimal strategy).

> Regardless of what approach you take through a library, it is always pena=
lized compile-time performance-wise for practical constructs over a languag=
e feature, which is the soul of what EWG#30 is currently all about.

Maybe it's about providing accessible tools to solve problems.

--=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=_BB392895-0923-4784-BB09-0DC5590D9FA7
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;09&ndash;17, at 11:48 PM, George Makrydakis &lt;<a href=3D"mailto:irr=
equietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Conte=
nt-Type">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    <div class=3D"moz-cite-prefix">On 09/16/2014 05:42 AM, David Krauss
      wrote:<br>
    </div>
    <blockquote cite=3D"mid:E021F21E-A607-444B-9203-02C1C8C51DF6@gmail.com"=
 type=3D"cite">
      <meta http-equiv=3D"Content-Type" content=3D"text/html;
        charset=3Dwindows-1252">
      <br>
      <div>
        <div>Wrapping a pack as a tuple type, i.e. merely naming <font face=
=3D"Courier">std::tuple&lt; T ... &gt;</font>, is
          essentially zero work for the compiler.</div>
        <div><br></div>
      </div>
    </blockquote>
    Only that it is not once you have to instantiate several <i><u><b>diffe=
rent
        </b></u></i>copies of std:tuple&lt;T...&gt; for each time</div></bl=
ockquote><div><br></div><div>You&rsquo;re not paying attention, and unfortu=
nately your experience is out of date.</div><div><br></div><div>A user shou=
ld only incur a <font face=3D"Courier">std::tuple</font> instantiation when=
 they actually need it as a runtime container. Accidental instantiation is =
an error which requires fixing.</div><div><br></div><div>Even for a low-ove=
rhead, empty type, accidental instantiation still represents significant ov=
erhead compared to just having an uninstantiated template-id, which is simi=
lar to an incomplete class.</div><br><blockquote type=3D"cite"><div text=3D=
"#000000" bgcolor=3D"#FFFFFF"> you
    wish to manipulate the contents of T... into an X..., or access the
    results of such manipulation. </div></blockquote><div><br></div><div>Ce=
rtainly not. You could have had an argument that older standard library imp=
lementations would instantiate <font face=3D"Courier">std::tuple</font> ins=
ide <font face=3D"Courier">std::tuple_element</font>, but mapping <font fac=
e=3D"Courier">tuple&lt;...&gt;</font> =3D&gt;&nbsp;<font face=3D"Courier">T=
....</font>&nbsp;=3D&gt;&nbsp;<font face=3D"Courier">F&lt;T&gt;...</font> wo=
n&rsquo;t instantiate anything besides <font face=3D"Courier">F</font>, and=
 that&rsquo;s been true since C++11 (and C++98 variadic emulation by nested=
 arguments&hellip; but that might not always have been an optimal strategy)=
..</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFF=
FF">Regardless of what approach you take
    through a library, it is always penalized compile-time
    performance-wise for practical constructs over a language feature,
    which is the soul of what EWG#30 is currently all about.<br></div></blo=
ckquote><div><br></div><div>Maybe it&rsquo;s about providing accessible too=
ls to solve problems.</div></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&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 />

--Apple-Mail=_BB392895-0923-4784-BB09-0DC5590D9FA7--

.

--Apple-Mail=_487D1D87-3385-4953-995D-A13625F0AB27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-18, at 12:08 AM, Agust=EDn K-ballo Berg=E9 <kaballo86@hotmail.co=
m> wrote:

> We also know more and more of what actually does cause compile-time perfo=
rmance to drop. Yet, I am not aware of any active effort to avoid or dimini=
sh the effect of name mangling in execution time and memory usage during co=
mpilation.

There was a recent discussion here, see "crypto-hash obfuscated namespaces.=
"

The resolution was that some implementation should take an initiative and a=
dd a language linkage specification (like extern "C++ stripped" or "C++ str=
ipped") with neutered mangling.

It should solve a number of pertinent problems, so it's only a matter of ti=
me...

--=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=_487D1D87-3385-4953-995D-A13625F0AB27
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;09&ndash;18, at 12:08 AM, Agust=EDn K-ballo Berg=E9 &lt;<a href=3D"ma=
ilto:kaballo86@hotmail.com">kaballo86@hotmail.com</a>&gt; wrote:</div><br c=
lass=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span style=3D=
"font-family: Helvetica; font-size: 12px; font-style: normal; font-variant:=
 normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: none; w=
hite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wi=
dth: 0px; float: none; display: inline !important;">We also know more and m=
ore of what actually does cause compile-time performance to drop. Yet, I am=
 not aware of any active effort to avoid or diminish the effect of name man=
gling in execution time and memory usage during compilation.</span><br styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; line-height: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px;"></blockquote></div><br><div>There was a recent discussion he=
re, see &ldquo;crypto-hash obfuscated namespaces.&rdquo;</div><div><br></di=
v><div>The resolution was that some implementation should take an initiativ=
e and add a language linkage specification (like <font face=3D"Courier">ext=
ern "C++ stripped"</font> or <font face=3D"Courier">"C++ stripped"</font>) =
with neutered mangling.</div><div><br></div><div>It should solve a number o=
f pertinent problems, so it&rsquo;s only a matter of time&hellip;</div><div=
><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&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 />

--Apple-Mail=_487D1D87-3385-4953-995D-A13625F0AB27--

.

This is a multi-part message in MIME format.
--------------080406020208010606000500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/17/2014 07:18 PM, David Krauss wrote:
>
> On 2014-09-17, at 11:48 PM, George Makrydakis <irrequietus@gmail.com
> <mailto:irrequietus@gmail.com>> wrote:
>
>>
>> On 09/16/2014 05:42 AM, David Krauss wrote:
>>>
>>> Wrapping a pack as a tuple type, i.e. merely naming std::tuple< T
>>> ... >, is essentially zero work for the compiler.
>>>
>> Only that it is not once you have to instantiate several /_*different
>> *_/copies of std:tuple<T...> for each time
>
> You're not paying attention, and unfortunately your experience is out
> of date.
>
You are taking that out of context and removing the rest in order to
proceed with your ad-hominem. Your choice:

std::tuple<int,int,int> // one instantiation

..... manipulation  of int,int,int in various ways and several std::tuple
afterwards ...

std::tuple<int,char,long> // two instantiations

That they are cached means nothing. Live with it.

>
> Regardless of what approach you take through a library, it is always
> penalized compile-time performance-wise for practical constructs over
> a language feature, which is the soul of what EWG#30 is currently all
> about.
>
> Maybe it's about providing accessible tools to solve problems.
>

You are clearly unable to understand packs, as you were clearly unable
to understand deducible context in face of multiple parameter packs in a
previous discussion. I do not think that you are actually contributing
to this discussion other than trying to overpower through tools you
obviously lack deep understanding of.

Regards,

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/.

--------------080406020208010606000500
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/17/2014 07:18 PM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:D614E923-D6AC-4B24-B247-6CE51618DA81@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On 2014&ndash;09&ndash;17, at 11:48 PM, George Makrydakis &lt;<a
            moz-do-not-send="true" href="mailto:irrequietus@gmail.com">irrequietus@gmail.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          <div text="#000000" bgcolor="#FFFFFF"> <br>
            <div class="moz-cite-prefix">On 09/16/2014 05:42 AM, David
              Krauss wrote:<br>
            </div>
            <blockquote
              cite="mid:E021F21E-A607-444B-9203-02C1C8C51DF6@gmail.com"
              type="cite">
              <meta http-equiv="Content-Type" content="text/html;
                charset=windows-1252">
              <br>
              <div>
                <div>Wrapping a pack as a tuple type, i.e. merely naming
                  <font face="Courier">std::tuple&lt; T ... &gt;</font>,
                  is essentially zero work for the compiler.</div>
                <div><br>
                </div>
              </div>
            </blockquote>
            Only that it is not once you have to instantiate several <i><u><b>different

                </b></u></i>copies of std:tuple&lt;T...&gt; for each
            time</div>
        </blockquote>
        <div><br>
        </div>
        <div>You&rsquo;re not paying attention, and unfortunately your
          experience is out of date.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    You are taking that out of context and removing the rest in order to
    proceed with your ad-hominem. Your choice:<br>
    <br>
    std::tuple&lt;int,int,int&gt; // one instantiation<br>
    <br>
    .... manipulation&nbsp; of int,int,int in various ways and several
    std::tuple afterwards ...<br>
    <br>
    std::tuple&lt;int,char,long&gt; // two instantiations<br>
    <br>
    That they are cached means nothing. Live with it.<br>
    <br>
    <blockquote
      cite="mid:D614E923-D6AC-4B24-B247-6CE51618DA81@gmail.com"
      type="cite">
      <div><br>
        <div text="#000000" bgcolor="#FFFFFF">Regardless of what
          approach you take through a library, it is always penalized
          compile-time performance-wise for practical constructs over a
          language feature, which is the soul of what EWG#30 is
          currently all about.<br>
        </div>
        <div><br>
        </div>
        <div>Maybe it&rsquo;s about providing accessible tools to solve
          problems.</div>
      </div>
      <br>
    </blockquote>
    <br>
    You are clearly unable to understand packs, as you were clearly
    unable to understand deducible context in face of multiple parameter
    packs in a previous discussion. I do not think that you are actually
    contributing to this discussion other than trying to overpower
    through tools you obviously lack deep understanding of.<br>
    <br>
    Regards,<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&quot; 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 />

--------------080406020208010606000500--

.

On 2014-09-18, at 12:43 AM, George Makrydakis <irrequietus@gmail.com> wrote:

> You are taking that out of context and removing the rest in order to proceed with your ad-hominem. Your choice:
>
> std::tuple<int,int,int> // one instantiation

No, zero instantiations. You're still missing it.

And I didn't remove anything, I replied to the remainder of the paragraph, in more depth.

> .... manipulation  of int,int,int in various ways and several std::tuple afterwards ...
>
> std::tuple<int,char,long> // two instantiations

Still zero.

> That they are cached means nothing. Live with it.

There's nothing to memoize. Template-ids can be used without instantiation until the class must be complete, e.g. for a member access.

Having bogus information to "cache," even a little bit to record an empty class, is already poor technique which might as well be considered an error.

> You are clearly unable to understand packs, as you were clearly unable to understand deducible context in face of multiple parameter packs in a previous discussion.

I recall that discussion, you put multiple packs in a primary class template. It was my fault for pointing out that error, rather than use my imagination to discern what you really meant to say.

> I do not think that you are actually contributing to this discussion other than trying to overpower through tools you obviously lack deep understanding of.

And you're trying to parlay authorship of C++98-based tools into design arguments for C++17.

--

---
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/.

.

On 17/09/2014 01:25 p.m., David Krauss wrote:
>
> On 2014-09-18, at 12:08 AM, Agust=EDn K-ballo Berg=E9 <kaballo86@hotmail.=
com
> <mailto:kaballo86@hotmail.com>> wrote:
>
>> We also know more and more of what actually does cause compile-time
>> performance to drop. Yet, I am not aware of any active effort to avoid
>> or diminish the effect of name mangling in execution time and memory
>> usage during compilation.
>
> There was a recent discussion here, see "crypto-hash obfuscated namespace=
s."
>
> The resolution was that some implementation should take an initiative
> and add a language linkage specification (like extern "C++ stripped" or
> "C++ stripped") with neutered mangling.
>
> It should solve a number of pertinent problems, so it's only a matter of
> time...

That certainly sounds promising, but that's not the most pressing=20
problem. The big hit comes from compilers using mangled names as unique=20
keys to lookup things; names which are kept around in memory with no=20
effort to reduce them further than what the ABI does, hashing them and=20
comparing them over and over again. This quickly becomes costly for=20
heavily templated code, where it doesn't take much to end up with=20
symbols of more than 1k chars (because namespaces and descriptive names=20
are a good thing). Recursive template instantiations are prohibitive not=20
because of the number of template instantiations (which is a concern of=20
the past), but because of the progressive length of the symbol of each=20
one of those instantiations.

Regards,
--=20
Agust=EDn K-ballo Berg=E9.-
http://talesofcpp.fusionfenix.com

--=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/.

.

This is a multi-part message in MIME format.
--------------040907080906080102090907
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable


On 09/17/2014 07:08 PM, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:
> On 17/09/2014 12:42 p.m., George Makrydakis wrote:
>>
>> On 09/16/2014 04:12 AM, Louis Dionne wrote:
>>> That being said, a valid objection would be the compile-time
>>> performance of
>>> std::tuple, which is really bad. I think this is a problem in itself
>>> and it
>>> ought to be addressed, but not by introducing a new construct that=20
>>> would
>>> address this issue only. If you look at Hana's implementation, the=20
>>> dirty
>>> tricks are very rare [1], and it would be easy to handle some of these
>>> with
>>> compiler-dependent intrinsics.
>>
>> The compile time performance of the std::tuple class template and its
>> accompanying std::get function template are shameful /because of the way
>> they are forced to be implemented due to the lack of language features
>> as those required by EWG#30 resolution/. Even having individual
>> parameter access, would make them trivial enough to not be even a
>> concern during "compile-time". The more you go down the recursive
>> instantiation and compiler intrinsic path for these things, the less you
>> are going to be able to have predictable performance between different
>> compilers - or even uniform behavior. That's why you need this at a
>> standard level.
>
> That sounds like a wild claim, and I would appreciate if you would=20
> expand on it a bit. After all, no single piece of `std::tuple` and=20
> related facilities is /forced/ to be implemented via recursive=20
> template instantiation. Furthermore, considering slow compile-times in=20
> heavily templated code nowadays is a direct consequence of name=20
> mangling, there would be hardly any benefit from using a language=20
> feature as opposed to an efficient library implementation; the same=20
> amount of mangling would be involved.

The sentence does not imply that recursive instantiations are to blame=20
alone nor does it imply that all implementations of std::tuple are made=20
through recursive instantiations. You could even use preprocessor stunts=20
and nested class templates with private access specified for that=20
matter. I would prefer addressing this in my draft (older revisions of=20
which already show how easy it becomes to implement std::tuple if some=20
features related to packs were already available). Also, if there is no=20
need for a "language" feature, why is EWG#30 open for 2+ years and=20
actively been worked upon?

>
>>> TL;DR
>>> For what it's worth, I would favor a well-thought library approach with
>>> (possibly) a compiler-backed implementation more than a change to the
>>> core language.
>>>
>>>
>> Sean said Stroustrup himself deliberated on the computational
>> complexities involved even for individual parameter access in a pack
>> through a library over a language feature. Given the status of EWG#30, I
>> seriously see no reason to not have fundamental pack manipulation as a
>> language feature over any other solution. Especially if it would allow
>> us to not require a third-party, unpredictably portable library
>> regardless of how good it actually is.
>
> As time goes by, we know more and more ways of avoiding big recursive=20
> template instantiations. I would like to say that anything that is not=20
> a fold can be implemented without recursion, but that'd be a hard=20
> claim to prove.

Because of the semantics of triple-dot, I have shown in the previous=20
post how naive /fmap-like/ behavior is implemented (see my reply to=20
Louis on this thread) because of triple-dot. Yes, we can avoid them in=20
certain occasions, but we don't have a way to avoid them always for=20
things as discussed by Dave Abrahams in his EWG#30 submission.

>
> We also know more and more of what actually does cause compile-time=20
> performance to drop. Yet, I am not aware of any active effort to avoid=20
> or diminish the effect of name mangling in execution time and memory=20
> usage during compilation.
One of the reasons of low compile-time performance is sloppy=20
implementation by compiler implementors; see clang++ vs everybody else=20
in ease of feature integration and at times, performance-wise. And that=20
is not even an "old" compiler as some others are. Yes, we get to see=20
more of what these things are actually about.

I think that favoring a library approach in order to appeal to=20
delegating C++ EWG BDFLs does not contribute to the technical=20
discussions for the benefit of the language, especially when EWG#30 is=20
open as a "language feature".

Regards,

George



--=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/.

--------------040907080906080102090907
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">
    <br>
    <div class=3D"moz-cite-prefix">On 09/17/2014 07:08 PM, Agust=C3=ADn K-b=
allo
      Berg=C3=A9 wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:BLU436-SMTP238084576358738621BC3D6A7B60@phx.gbl"
      type=3D"cite">On 17/09/2014 12:42 p.m., George Makrydakis wrote:
      <br>
      <blockquote type=3D"cite">
        <br>
        On 09/16/2014 04:12 AM, Louis Dionne wrote:
        <br>
        <blockquote type=3D"cite">That being said, a valid objection would
          be the compile-time
          <br>
          performance of
          <br>
          std::tuple, which is really bad. I think this is a problem in
          itself
          <br>
          and it
          <br>
          ought to be addressed, but not by introducing a new construct
          that would
          <br>
          address this issue only. If you look at Hana's implementation,
          the dirty
          <br>
          tricks are very rare [1], and it would be easy to handle some
          of these
          <br>
          with
          <br>
          compiler-dependent intrinsics.
          <br>
        </blockquote>
        <br>
        The compile time performance of the std::tuple class template
        and its
        <br>
        accompanying std::get function template are shameful /because of
        the way
        <br>
        they are forced to be implemented due to the lack of language
        features
        <br>
        as those required by EWG#30 resolution/. Even having individual
        <br>
        parameter access, would make them trivial enough to not be even
        a
        <br>
        concern during "compile-time". The more you go down the
        recursive
        <br>
        instantiation and compiler intrinsic path for these things, the
        less you
        <br>
        are going to be able to have predictable performance between
        different
        <br>
        compilers - or even uniform behavior. That's why you need this
        at a
        <br>
        standard level.
        <br>
      </blockquote>
      <br>
      That sounds like a wild claim, and I would appreciate if you would
      expand on it a bit. After all, no single piece of `std::tuple` and
      related facilities is /forced/ to be implemented via recursive
      template instantiation. Furthermore, considering slow
      compile-times in heavily templated code nowadays is a direct
      consequence of name mangling, there would be hardly any benefit
      from using a language feature as opposed to an efficient library
      implementation; the same amount of mangling would be involved.
      <br>
    </blockquote>
    <br>
    The sentence does not imply that recursive instantiations are to
    blame alone nor does it imply that all implementations of std::tuple
    are made through recursive instantiations. You could even use
    preprocessor stunts and nested class templates with private access
    specified for that matter. I would prefer addressing this in my
    draft (older revisions of which already show how easy it becomes to
    implement std::tuple if some features related to packs were already
    available). Also, if there is no need for a "language" feature, why
    is EWG#30 open for 2+ years and actively been worked upon?<br>
    <br>
    <blockquote
      cite=3D"mid:BLU436-SMTP238084576358738621BC3D6A7B60@phx.gbl"
      type=3D"cite">
      <br>
      <blockquote type=3D"cite">
        <blockquote type=3D"cite">TL;DR
          <br>
          For what it's worth, I would favor a well-thought library
          approach with
          <br>
          (possibly) a compiler-backed implementation more than a change
          to the
          <br>
          core language.
          <br>
          <br>
          <br>
        </blockquote>
        Sean said Stroustrup himself deliberated on the computational
        <br>
        complexities involved even for individual parameter access in a
        pack
        <br>
        through a library over a language feature. Given the status of
        EWG#30, I
        <br>
        seriously see no reason to not have fundamental pack
        manipulation as a
        <br>
        language feature over any other solution. Especially if it would
        allow
        <br>
        us to not require a third-party, unpredictably portable library
        <br>
        regardless of how good it actually is.
        <br>
      </blockquote>
      <br>
      As time goes by, we know more and more ways of avoiding big
      recursive template instantiations. I would like to say that
      anything that is not a fold can be implemented without recursion,
      but that'd be a hard claim to prove.<br>
    </blockquote>
    <br>
    Because of the semantics of triple-dot, I have shown in the previous
    post how naive <i>fmap-like</i> behavior is implemented (see my
    reply to Louis on this thread) because of triple-dot. Yes, we can
    avoid them in certain occasions, but we don't have a way to avoid
    them always for things as discussed by Dave Abrahams in his EWG#30
    submission.<br>
    <br>
    <blockquote
      cite=3D"mid:BLU436-SMTP238084576358738621BC3D6A7B60@phx.gbl"
      type=3D"cite">
      <br>
      We also know more and more of what actually does cause
      compile-time performance to drop. Yet, I am not aware of any
      active effort to avoid or diminish the effect of name mangling in
      execution time and memory usage during compilation.<br>
    </blockquote>
    One of the reasons of low compile-time performance is sloppy
    implementation by compiler implementors; see clang++ vs everybody
    else in ease of feature integration and at times, performance-wise.
    And that is not even an "old" compiler as some others are. Yes, we
    get to see more of what these things are actually about.<br>
    <br>
    I think that favoring a library approach in order to appeal to
    delegating C++ EWG BDFLs does not contribute to the technical
    discussions for the benefit of the language, especially when EWG#30
    is open as a "language feature".<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <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&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 />

--------------040907080906080102090907--

.

On 2014-09-18, at 12:53 AM, Agust=EDn K-ballo Berg=E9 <kaballo86@hotmail.co=
m> wrote:

> That certainly sounds promising, but that's not the most pressing problem=
.. The big hit comes from compilers using mangled names as unique keys to lo=
okup things; names which are kept around in memory with no effort to reduce=
 them further than what the ABI does,

A cursory check into GCC led me to believe that the language linkage facili=
ty is one and the same with the mangling facility. A compact mangled ABI re=
presentation should automatically apply internally as well.

> hashing them and comparing them over and over again. This quickly becomes=
 costly for heavily templated code, where it doesn't take much to end up wi=
th symbols of more than 1k chars (because namespaces and descriptive names =
are a good thing). Recursive template instantiations are prohibitive not be=
cause of the number of template instantiations (which is a concern of the p=
ast), but because of the progressive length of the symbol of each one of th=
ose instantiations.

Hmm, I'll take your word for it, but I also have ~1KB symbols and 10+ level=
s of depth and a slow compile usually just indicates that I generated a big=
ger binary.

--=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/.

.

This is a multi-part message in MIME format.
--------------010704050100040108080200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/17/2014 07:55 PM, David Krauss wrote:
> On 2014-09-18, at 12:43 AM, George Makrydakis <irrequietus@gmail.com> wrote:
>
>> You are taking that out of context and removing the rest in order to proceed with your ad-hominem. Your choice:
>>
>> std::tuple<int,int,int> // one instantiation
> No, zero instantiations. You're still missing it.
>
> And I didn't remove anything, I replied to the remainder of the paragraph, in more depth.
You obviously did not, but I digress. You arguments are interesting up
to a certain point.
>
>> .... manipulation  of int,int,int in various ways and several std::tuple afterwards ...
>>
>> std::tuple<int,char,long> // two instantiations
> Still zero.
Try manipulating them through various changes in the parameter pack and
measure. Enjoy.
>
>> That they are cached means nothing. Live with it.
I repeat again that statement: caching means nothing. Stop thinking that
other people use std::tuple as a poor substitute for boost::mpl the way
you do. That is not the case, nor is there a burden of proof that is not
already spoken of as taken for granted through Abrahams' EWG#30.
>
>> You are clearly unable to understand packs, as you were clearly unable to understand deducible context in face of multiple parameter packs in a previous discussion.
> I recall that discussion, you put multiple packs in a primary class template. It was my fault for pointing out that error, rather than use my imagination to discern what you really meant to say.

You did not see the actual deducible context and were corrected by both
Ville Voutillainen and I. Even monkeys make mistakes, as a Japanese
proverbs say. If it makes you feel any better, I am not implying that
you are not aware of how multiple packs are used, I am saying that you
have not been using them creatively enough to get a deeper understanding
of why parameter packs, in general, are crippled.
>> I do not think that you are actually contributing to this discussion other than trying to overpower through tools you obviously lack deep understanding of.
> And you're trying to parlay authorship of C++98-based tools into design arguments for C++17.
Another ad-hominem that does not suit your level of expertise. I am not
trying to parlay anything, I have my own work - at a language feature
level - that meticulously cites everybody else /unlike/ what other
people do; evolving features that from boost::mpl into language features
is what happened with parameter packs. Would you think that the
proponents of variadic packs for C++11 "parlayed authorship" on them?

Do notice that the problems that annotated template parameter packs aim
to solve are not the ones you are referring to or strictly related to
boost::mpl like facilities /alone/. Feel free to wait for the final
draft and N-number before you fall a victim of your own fallacies.

Regards,

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/.

--------------010704050100040108080200
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/17/2014 07:55 PM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
      type="cite">
      <pre wrap="">
On 2014-09-18, at 12:43 AM, George Makrydakis <a class="moz-txt-link-rfc2396E" href="mailto:irrequietus@gmail.com">&lt;irrequietus@gmail.com&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">You are taking that out of context and removing the rest in order to proceed with your ad-hominem. Your choice:

std::tuple&lt;int,int,int&gt; // one instantiation
</pre>
      </blockquote>
      <pre wrap="">
No, zero instantiations. You're still missing it.

And I didn't remove anything, I replied to the remainder of the paragraph, in more depth.</pre>
    </blockquote>
    You obviously did not, but I digress. You arguments are interesting
    up to a certain point.<br>
    <blockquote
      cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">.... manipulation  of int,int,int in various ways and several std::tuple afterwards ...

std::tuple&lt;int,char,long&gt; // two instantiations
</pre>
      </blockquote>
      <pre wrap="">
Still zero.</pre>
    </blockquote>
    Try manipulating them through various changes in the parameter pack
    and measure. Enjoy.<br>
    <blockquote
      cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">That they are cached means nothing. Live with it.
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    I repeat again that statement: caching means nothing. Stop thinking
    that other people use std::tuple as a poor substitute for boost::mpl
    the way you do. That is not the case, nor is there a burden of proof
    that is not already spoken of as taken for granted through Abrahams'
    EWG#30.<br>
    <blockquote
      cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">You are clearly unable to understand packs, as you were clearly unable to understand deducible context in face of multiple parameter packs in a previous discussion.
</pre>
      </blockquote>
      <pre wrap="">
I recall that discussion, you put multiple packs in a primary class template. It was my fault for pointing out that error, rather than use my imagination to discern what you really meant to say.</pre>
    </blockquote>
    <br>
    You did not see the actual deducible context and were corrected by
    both Ville Voutillainen and I. Even monkeys make mistakes, as a
    Japanese proverbs say. If it makes you feel any better, I am not
    implying that you are not aware of how multiple packs are used, I am
    saying that you have not been using them creatively enough to get a
    deeper understanding of why parameter packs, in general, are
    crippled.<br>
    <blockquote
      cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">I do not think that you are actually contributing to this discussion other than trying to overpower through tools you obviously lack deep understanding of.
</pre>
      </blockquote>
      <pre wrap="">
And you're trying to parlay authorship of C++98-based tools into design arguments for C++17.</pre>
    </blockquote>
    Another ad-hominem that does not suit your level of expertise. I am
    not trying to parlay anything, I have my own work - at a language
    feature level - that meticulously cites everybody else <i>unlike</i>
    what other people do; evolving features that from boost::mpl into
    language features is what happened with parameter packs. Would you
    think that the proponents of variadic packs for C++11 "parlayed
    authorship" on them?<br>
    <br>
    Do notice that the problems that annotated template parameter packs
    aim to solve are not the ones you are referring to or strictly
    related to boost::mpl like facilities <i>alone</i>. Feel free to
    wait for the final draft and N-number before you fall a victim of
    your own fallacies.<br>
    <br>
    Regards,<br>
    <br>
    George<br>
    <br>
    <br>
    <br>
    <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&quot; 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 />

--------------010704050100040108080200--

.

On 17/09/2014 01:59 p.m., George Makrydakis wrote:
>
> On 09/17/2014 07:08 PM, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:
>> On 17/09/2014 12:42 p.m., George Makrydakis wrote:
>>>
>>> On 09/16/2014 04:12 AM, Louis Dionne wrote:
>>>> That being said, a valid objection would be the compile-time
>>>> performance of
>>>> std::tuple, which is really bad. I think this is a problem in itself
>>>> and it
>>>> ought to be addressed, but not by introducing a new construct that
>>>> would
>>>> address this issue only. If you look at Hana's implementation, the
>>>> dirty
>>>> tricks are very rare [1], and it would be easy to handle some of these
>>>> with
>>>> compiler-dependent intrinsics.
>>>
>>> The compile time performance of the std::tuple class template and its
>>> accompanying std::get function template are shameful /because of the wa=
y
>>> they are forced to be implemented due to the lack of language features
>>> as those required by EWG#30 resolution/. Even having individual
>>> parameter access, would make them trivial enough to not be even a
>>> concern during "compile-time". The more you go down the recursive
>>> instantiation and compiler intrinsic path for these things, the less yo=
u
>>> are going to be able to have predictable performance between different
>>> compilers - or even uniform behavior. That's why you need this at a
>>> standard level.
>>
>> That sounds like a wild claim, and I would appreciate if you would
>> expand on it a bit. After all, no single piece of `std::tuple` and
>> related facilities is /forced/ to be implemented via recursive
>> template instantiation. Furthermore, considering slow compile-times in
>> heavily templated code nowadays is a direct consequence of name
>> mangling, there would be hardly any benefit from using a language
>> feature as opposed to an efficient library implementation; the same
>> amount of mangling would be involved.
>
> The sentence does not imply that recursive instantiations are to blame
> alone nor does it imply that all implementations of std::tuple are made
> through recursive instantiations. You could even use preprocessor stunts
> and nested class templates with private access specified for that
> matter. I would prefer addressing this in my draft (older revisions of
> which already show how easy it becomes to implement std::tuple if some
> features related to packs were already available). Also, if there is no
> need for a "language" feature, why is EWG#30 open for 2+ years and
> actively been worked upon?

It is not my position that there is no need for a language feature (see=20
below). It is my impression, and only my impression, that the issue=20
remains open because we continue to gather more and more knowledge on=20
the subject. For instance, we know now that the downsides claimed in=20
that issue no longer necessary hold, as we know that there is nothing in=20
the standard that forces those issues to exist in the first place (it's=20
just QoI).

>>>> TL;DR
>>>> For what it's worth, I would favor a well-thought library approach wit=
h
>>>> (possibly) a compiler-backed implementation more than a change to the
>>>> core language.
>>>>
>>>>
>>> Sean said Stroustrup himself deliberated on the computational
>>> complexities involved even for individual parameter access in a pack
>>> through a library over a language feature. Given the status of EWG#30, =
I
>>> seriously see no reason to not have fundamental pack manipulation as a
>>> language feature over any other solution. Especially if it would allow
>>> us to not require a third-party, unpredictably portable library
>>> regardless of how good it actually is.
>>
>> As time goes by, we know more and more ways of avoiding big recursive
>> template instantiations. I would like to say that anything that is not
>> a fold can be implemented without recursion, but that'd be a hard
>> claim to prove.
>
> Because of the semantics of triple-dot, I have shown in the previous
> post how naive /fmap-like/ behavior is implemented (see my reply to
> Louis on this thread) because of triple-dot. Yes, we can avoid them in
> certain occasions, but we don't have a way to avoid them always for
> things as discussed by Dave Abrahams in his EWG#30 submission.
>
>>
>> We also know more and more of what actually does cause compile-time
>> performance to drop. Yet, I am not aware of any active effort to avoid
>> or diminish the effect of name mangling in execution time and memory
>> usage during compilation.
> One of the reasons of low compile-time performance is sloppy
> implementation by compiler implementors; see clang++ vs everybody else
> in ease of feature integration and at times, performance-wise. And that
> is not even an "old" compiler as some others are. Yes, we get to see
> more of what these things are actually about.
>
> I think that favoring a library approach in order to appeal to
> delegating C++ EWG BDFLs does not contribute to the technical
> discussions for the benefit of the language, especially when EWG#30 is
> open as a "language feature".

I am not favoring a library approach over a language feature. I am=20
merely stating that compile-time performance is not a sustainable reason=20
to favor a language feature, as the overheads come not from the feature=20
but from how both library and compilers are implemented. That said, I=20
would love to be able to stop playing the kind of tricks that takes to=20
have an efficient implementation. Simple things should be accomplished=20
in simple ways.

Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com

--=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_21_1357208982.1410974242264
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, 16 September 2014 22:51:08 UTC-4, David Krauss wrote:

On 2014=E2=80=9309=E2=80=9316, at 8:35 PM, Louis Dionne <ldio...@gmail.com>=
 wrote:
> >
> > [...]
> >
> > Also, it is possible to index a tuple without "walking up to the index"
> > (at least in a recursive manner); see [3].

> Fair nuff, and good idea.

The original idea is by Richard Smith.

> [...]
>=20
> > [1]: http://imgur.com/UoQZ7xd
> > [2]:=20
https://github.com/ldionne/hana-cppcon-2014/tree/gh-pages/code/benchmark/el=
em
>
> I don=E2=80=99t know this preprocessor, but the program looks vaguely lik=
e=20
overload=20
> set metaprogramming.

I'm not sure I understand your comment correctly, but the markup I use in=
=20
those
files is ERB[1] templating. I use it to generate files which I then=20
benchmark.

Regards,
Louis

[1]: http://en.wikipedia.org/wiki/ERuby

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

<div dir=3D"ltr"><div>On Tuesday, 16 September 2014 22:51:08 UTC-4, David K=
rauss wrote:</div><div><br></div><div>On 2014=E2=80=9309=E2=80=9316, at 8:3=
5 PM, Louis Dionne &lt;ldio...@gmail.com&gt; wrote:</div><div>&gt; &gt;</di=
v><div>&gt; &gt; [...]</div><div>&gt; &gt;</div><div>&gt; &gt; Also, it is =
possible to index a tuple without "walking up to the index"</div><div>&gt; =
&gt; (at least in a recursive manner); see [3].</div><div><br></div><div>&g=
t; Fair nuff, and good idea.</div><div><br></div><div>The original idea is =
by Richard Smith.</div><div><br></div><div>&gt; [...]</div><div>&gt;&nbsp;<=
/div><div>&gt; &gt; [1]: http://imgur.com/UoQZ7xd</div><div>&gt; &gt; [2]: =
https://github.com/ldionne/hana-cppcon-2014/tree/gh-pages/code/benchmark/el=
em</div><div>&gt;</div><div>&gt; I don=E2=80=99t know this preprocessor, bu=
t the program looks vaguely like overload&nbsp;</div><div>&gt; set metaprog=
ramming.</div><div><br></div><div>I'm not sure I understand your comment co=
rrectly, but the markup I use in those</div><div>files is ERB[1] templating=
.. I use it to generate files which I then benchmark.</div><div><br></div><d=
iv>Regards,</div><div>Louis</div><div><br></div><div>[1]: http://en.wikiped=
ia.org/wiki/ERuby</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_21_1357208982.1410974242264--

.

On 09/17/2014 07:53 PM, Agust=EDn K-ballo Berg=E9 wrote:
> On 17/09/2014 01:25 p.m., David Krauss wrote:
>>
>>
[... cutting brief, because everybody knows that ...]
>
> Recursive template instantiations are prohibitive not because of the=20
> number of template instantiations (which is a concern of the past),=20
> but because of the progressive length of the symbol of each one of=20
> those instantiations.
>
That is a valid technical point; the problem is that in any case it=20
translates to recursive template instantiations being costly because of=20
sloppy compiler implementation of such recursion. Granted that template=20
meta-programming is not for Jar Jar Binks level of C++ programmers some=20
would like C++ to be for, so this does not get much attention. I would=20
have liked such recursive constructs to be implemented differently in=20
compilers, given that recursive instantiations are a fundamental=20
computational construct for any meaningful catamorphism (aka "folds",=20
and even more).

Regards,

George

--=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=_F058E62A-97F3-4FF7-830C-B23EED282BCA
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-18, at 1:10 AM, George Makrydakis <irrequietus@gmail.com> wrote:

>>> std::tuple<int,char,long> // two instantiations
>> Still zero.
> Try manipulating them through various changes in the parameter pack and measure. Enjoy.

What would you gain by instantiating the tuple? It has no members of interest to metaprogramming, it's just purely a runtime container class.

As a general pattern:

template< typename >
struct manip;

template< typename ... t >
struct manip< tuple< t ... > > {
    typedef std::tuple< f< t > ... > type;
};

Unpack, process, repack. No instantiations that do not serve a useful compile-time purpose.

--

---
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/.

--Apple-Mail=_F058E62A-97F3-4FF7-830C-B23EED282BCA
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;09&ndash;18, at 1:10 AM, George Makrydakis &lt;<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div text=3D"#000000" b=
gcolor=3D"#FFFFFF"><blockquote cite=3D"mid:F0F015F2-D87C-47BE-8C51-973581BA=
FDF1@gmail.com" type=3D"cite" style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type=3D"cite">=
<pre wrap=3D"">std::tuple&lt;int,char,long&gt; // two instantiations
</pre></blockquote><pre wrap=3D"">Still zero.</pre></blockquote><span style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; background-color: rgb(255, 255, 255); float: none; display: in=
line !important;">Try manipulating them through various changes in the para=
meter pack and measure. Enjoy.</span></div></blockquote><br></div><div>What=
 would you gain by instantiating the tuple? It has no members of interest t=
o metaprogramming, it&rsquo;s just purely a runtime container class.</div><=
div><br></div><div>As a general pattern:</div><br><div><font face=3D"Courie=
r">template&lt; typename &gt;</font></div><div><font face=3D"Courier">struc=
t manip;</font></div><div><font face=3D"Courier"><br></font></div><div><fon=
t face=3D"Courier">template&lt; typename ... t &gt;</font></div><div><font =
face=3D"Courier">struct manip&lt; tuple&lt; t ... &gt; &gt; {</font></div><=
div><font face=3D"Courier">&nbsp; &nbsp; typedef std::tuple&lt; f&lt; t &gt=
; ... &gt; type;</font></div><div><font face=3D"Courier">};</font></div><di=
v><br></div><div>Unpack, process, repack. No instantiations that do not ser=
ve a useful compile-time purpose.</div><div><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&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 />

--Apple-Mail=_F058E62A-97F3-4FF7-830C-B23EED282BCA--

.

This is a multi-part message in MIME format.
--------------050600060403030205080505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/17/2014 08:18 PM, David Krauss wrote:
>
> On 2014-09-18, at 1:10 AM, George Makrydakis <irrequietus@gmail.com
> <mailto:irrequietus@gmail.com>> wrote:
>
>>>> std::tuple<int,char,long> // two instantiations
>>> Still zero.
>> Try manipulating them through various changes in the parameter pack
>> and measure. Enjoy.
>
> What would you gain by instantiating the tuple? It has no members of
> interest to metaprogramming, it's just purely a runtime container class.
>
> As a general pattern:
>
> template< typename >
> struct manip;
>
> template< typename ... t >
> struct manip< tuple< t ... > > {
>     typedef std::tuple< f< t > ... > type;
> };
>
> Unpack, process, repack. No instantiations that do not serve a useful
> compile-time purpose.
>
You have not altered the pack, you just used fmap-like behavior
(structure preserving) just as I described in a previous post by using
the triple-dot expansion semantics (which are a language feature) and
give you that 0 cost. Imagine doing something more meaningful like
reversing the order of the parameters in the pack while interleaving by
inserting new types within them or changing those types to other types.

You seem to be considering catamorphisms, anamorphisms and structure
preserving transformations of parameter packs as mere "taxonomy",
instead of a language people use to communicate on such matters (see
foldl, unfoldl, scanl etc and their implementations in C++
metaprogramming libraries including boost::mpl and boost::hana).

Using std::tuple as a boost::mpl or boost::hana typelist construct
substitute is poor judgement at best. As are constexpr overloads of
<algorithm> members when it comes to manipulating type and template-type
parameters (they are not even suitable for such uses, just for non-type
processing, aka values - and then big "ifs" involved).

In the end, I think that you believe to be "right" because you are
unknowingly ignoring the actual context of the problems we are
discussing about. And, tossing things out of context is a pretty pointless.

Respectfully, I do not have problems with your arguments, because they
fail to address (yet) what everybody else is trying to. Keep the
ad-hominem minimal.

Regards,

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/.

--------------050600060403030205080505
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/17/2014 08:18 PM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:D1491DAF-27E5-4D41-8924-379A23D4B0AF@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On 2014&ndash;09&ndash;18, at 1:10 AM, George Makrydakis &lt;<a
            moz-do-not-send="true" href="mailto:irrequietus@gmail.com">irrequietus@gmail.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div text="#000000" bgcolor="#FFFFFF">
            <blockquote
              cite="mid:F0F015F2-D87C-47BE-8C51-973581BAFDF1@gmail.com"
              type="cite" style="font-family: Helvetica; font-size:
              12px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
              <blockquote type="cite">
                <pre wrap="">std::tuple&lt;int,char,long&gt; // two instantiations
</pre>
              </blockquote>
              <pre wrap="">Still zero.</pre>
            </blockquote>
            <span style="font-family: Helvetica; font-size: 12px;
              font-style: normal; font-variant: normal; font-weight:
              normal; letter-spacing: normal; line-height: normal;
              orphans: auto; text-align: start; text-indent: 0px;
              text-transform: none; white-space: normal; widows: auto;
              word-spacing: 0px; -webkit-text-stroke-width: 0px;
              background-color: rgb(255, 255, 255); float: none;
              display: inline !important;">Try manipulating them through
              various changes in the parameter pack and measure. Enjoy.</span></div>
        </blockquote>
        <br>
      </div>
      <div>What would you gain by instantiating the tuple? It has no
        members of interest to metaprogramming, it&rsquo;s just purely a
        runtime container class.</div>
      <div><br>
      </div>
      <div>As a general pattern:</div>
      <br>
      <div><font face="Courier">template&lt; typename &gt;</font></div>
      <div><font face="Courier">struct manip;</font></div>
      <div><font face="Courier"><br>
        </font></div>
      <div><font face="Courier">template&lt; typename ... t &gt;</font></div>
      <div><font face="Courier">struct manip&lt; tuple&lt; t ... &gt;
          &gt; {</font></div>
      <div><font face="Courier">&nbsp; &nbsp; typedef std::tuple&lt; f&lt; t &gt;
          ... &gt; type;</font></div>
      <div><font face="Courier">};</font></div>
      <div><br>
      </div>
      <div>Unpack, process, repack. No instantiations that do not serve
        a useful compile-time purpose.</div>
      <div><br>
      </div>
    </blockquote>
    You have not altered the pack, you just used fmap-like behavior
    (structure preserving) just as I described in a previous post by
    using the triple-dot expansion semantics (which are a language
    feature) and give you that 0 cost. Imagine doing something more
    meaningful like reversing the order of the parameters in the pack
    while interleaving by inserting new types within them or changing
    those types to other types.<br>
    <br>
    You seem to be considering catamorphisms, anamorphisms and structure
    preserving transformations of parameter packs as mere "taxonomy",
    instead of a language people use to communicate on such matters (see
    foldl, unfoldl, scanl etc and their implementations in C++
    metaprogramming libraries including boost::mpl and boost::hana).<br>
    <br>
    Using std::tuple as a boost::mpl or boost::hana typelist construct
    substitute is poor judgement at best. As are constexpr overloads of
    &lt;algorithm&gt; members when it comes to manipulating type and
    template-type parameters (they are not even suitable for such uses,
    just for non-type processing, aka values - and then big "ifs"
    involved).<br>
    <br>
    In the end, I think that you believe to be "right" because you are
    unknowingly ignoring the actual context of the problems we are
    discussing about. And, tossing things out of context is a pretty
    pointless.<br>
    <br>
    Respectfully, I do not have problems with your arguments, because
    they fail to address (yet) what everybody else is trying to. Keep
    the ad-hominem minimal.<br>
    <br>
    Regards,<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&quot; 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 />

--------------050600060403030205080505--

.

This is a multi-part message in MIME format.
--------------010603030608060105030502
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable


On 09/17/2014 08:14 PM, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:
> On 17/09/2014 01:59 p.m., George Makrydakis wrote:
[ .. snipped because already discussed ... ]
>> The sentence does not imply that recursive instantiations are to blame
>> alone nor does it imply that all implementations of std::tuple are made
>> through recursive instantiations. You could even use preprocessor stunts
>> and nested class templates with private access specified for that
>> matter. I would prefer addressing this in my draft (older revisions of
>> which already show how easy it becomes to implement std::tuple if some
>> features related to packs were already available). Also, if there is no
>> need for a "language" feature, why is EWG#30 open for 2+ years and
>> actively been worked upon?
>
> It is not my position that there is no need for a language feature=20
> (see below). It is my impression, and only my impression, that the=20
> issue remains open because we continue to gather more and more=20
> knowledge on the subject. For instance, we know now that the downsides=20
> claimed in that issue no longer necessary hold, as we know that there=20
> is nothing in the standard that forces those issues to exist in the=20
> first place (it's just QoI).
>
I can agree with that statement; should this be an argument /*for not=20
exploring language features*/? I think not, since that is not your=20
position. So we agree over substance.

[... snipped because addressed elsewhere ...]
>>>
>>> As time goes by, we know more and more ways of avoiding big recursive
>>> template instantiations. I would like to say that anything that is not
>>> a fold can be implemented without recursion, but that'd be a hard
>>> claim to prove.
>>
>> Because of the semantics of triple-dot, I have shown in the previous
>> post how naive /fmap-like/ behavior is implemented (see my reply to
>> Louis on this thread) because of triple-dot. Yes, we can avoid them in
>> certain occasions, but we don't have a way to avoid them always for
>> things as discussed by Dave Abrahams in his EWG#30 submission.
>>
>>>
>>> We also know more and more of what actually does cause compile-time
>>> performance to drop. Yet, I am not aware of any active effort to avoid
>>> or diminish the effect of name mangling in execution time and memory
>>> usage during compilation.
>> One of the reasons of low compile-time performance is sloppy
>> implementation by compiler implementors; see clang++ vs everybody else
>> in ease of feature integration and at times, performance-wise. And that
>> is not even an "old" compiler as some others are. Yes, we get to see
>> more of what these things are actually about.
>>
>> I think that favoring a library approach in order to appeal to
>> delegating C++ EWG BDFLs does not contribute to the technical
>> discussions for the benefit of the language, especially when EWG#30 is
>> open as a "language feature".
>
> I am not favoring a library approach over a language feature. I am=20
> merely stating that compile-time performance is not a sustainable=20
> reason to favor a language feature, as the overheads come not from the=20
> feature but from how both library and compilers are implemented. That=20
> said, I would love to be able to stop playing the kind of tricks that=20
> takes to have an efficient implementation. Simple things should be=20
> accomplished in simple ways.
Again we agree over substance; as I state elsewhere and on this thread,=20
the problem is not just compile-time performance, but the fact that for=20
trivial operations, you need to write a whole bunch of boilerplate that=20
is unnecessary given how often serious C++ makes use of them. By=20
analogy, we should not have had variadic packs in C++11 because the=20
C++03 boost implementation was good enough. Obviously, neither=20
Stroustrup nor Gregor (who authored the papers involved for C++11)=20
agreed on NOT having parameter packs to begin with. It is not a question=20
of whether packs should evolve or not, but when will that happen.

I think that your conservative view is objective given its substance and=20
motivation; it aims to see which solution is better. I can happily live=20
with packs remaining as they are. Also I do not particularly care about=20
whether language features related to packs as I "vision" them are to be=20
"encouraged" or not. /That is not what I am after.//
/
What matters to is to have an adequately deep treatise of the problems=20
involved as a service to the language - not for pleasing C++ EWG BDFLs I=20
may have valid /*technical*/ reasons to disagree with, in both substance=20
and form of any of their non-arguments involved. If they just come up=20
implementing the same things after some time that this is over,=20
rehashing syntax or whatever else, it is not of my concern. The language=20
will be served. As some of them will be :)

Proofs by construction are more important over social networking and=20
attempts to downplay any contribution by outsider volunteers.

Regards,

George

--=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/.

--------------010603030608060105030502
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">
    <br>
    <div class=3D"moz-cite-prefix">On 09/17/2014 08:14 PM, Agust=C3=ADn K-b=
allo
      Berg=C3=A9 wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:BLU437-SMTP36DF2E481FEAF6F190530AA7B60@phx.gbl"
      type=3D"cite">On 17/09/2014 01:59 p.m., George Makrydakis wrote:
      <br>
    </blockquote>
    [ .. snipped because already discussed ... ]<br>
    <blockquote
      cite=3D"mid:BLU437-SMTP36DF2E481FEAF6F190530AA7B60@phx.gbl"
      type=3D"cite">
      <blockquote type=3D"cite">The sentence does not imply that recursive
        instantiations are to blame
        <br>
        alone nor does it imply that all implementations of std::tuple
        are made
        <br>
        through recursive instantiations. You could even use
        preprocessor stunts
        <br>
        and nested class templates with private access specified for
        that
        <br>
        matter. I would prefer addressing this in my draft (older
        revisions of
        <br>
        which already show how easy it becomes to implement std::tuple
        if some
        <br>
        features related to packs were already available). Also, if
        there is no
        <br>
        need for a "language" feature, why is EWG#30 open for 2+ years
        and
        <br>
        actively been worked upon?
        <br>
      </blockquote>
      <br>
      It is not my position that there is no need for a language feature
      (see below). It is my impression, and only my impression, that the
      issue remains open because we continue to gather more and more
      knowledge on the subject. For instance, we know now that the
      downsides claimed in that issue no longer necessary hold, as we
      know that there is nothing in the standard that forces those
      issues to exist in the first place (it's just QoI).
      <br>
      <br>
    </blockquote>
    I can agree with that statement; should this be an argument <i><b>for
        not exploring language features</b></i>? I think not, since that
    is not your position. So we agree over substance.<br>
    <br>
    [... snipped because addressed elsewhere ...]<br>
    <blockquote
      cite=3D"mid:BLU437-SMTP36DF2E481FEAF6F190530AA7B60@phx.gbl"
      type=3D"cite">
      <blockquote type=3D"cite">
        <blockquote type=3D"cite"><br>
          As time goes by, we know more and more ways of avoiding big
          recursive
          <br>
          template instantiations. I would like to say that anything
          that is not
          <br>
          a fold can be implemented without recursion, but that'd be a
          hard
          <br>
          claim to prove.
          <br>
        </blockquote>
        <br>
        Because of the semantics of triple-dot, I have shown in the
        previous
        <br>
        post how naive /fmap-like/ behavior is implemented (see my reply
        to
        <br>
        Louis on this thread) because of triple-dot. Yes, we can avoid
        them in
        <br>
        certain occasions, but we don't have a way to avoid them always
        for
        <br>
        things as discussed by Dave Abrahams in his EWG#30 submission.
        <br>
        <br>
        <blockquote type=3D"cite">
          <br>
          We also know more and more of what actually does cause
          compile-time
          <br>
          performance to drop. Yet, I am not aware of any active effort
          to avoid
          <br>
          or diminish the effect of name mangling in execution time and
          memory
          <br>
          usage during compilation.
          <br>
        </blockquote>
        One of the reasons of low compile-time performance is sloppy
        <br>
        implementation by compiler implementors; see clang++ vs
        everybody else
        <br>
        in ease of feature integration and at times, performance-wise.
        And that
        <br>
        is not even an "old" compiler as some others are. Yes, we get to
        see
        <br>
        more of what these things are actually about.
        <br>
        <br>
        I think that favoring a library approach in order to appeal to
        <br>
        delegating C++ EWG BDFLs does not contribute to the technical
        <br>
        discussions for the benefit of the language, especially when
        EWG#30 is
        <br>
        open as a "language feature".
        <br>
      </blockquote>
      <br>
      I am not favoring a library approach over a language feature. I am
      merely stating that compile-time performance is not a sustainable
      reason to favor a language feature, as the overheads come not from
      the feature but from how both library and compilers are
      implemented. That said, I would love to be able to stop playing
      the kind of tricks that takes to have an efficient implementation.
      Simple things should be accomplished in simple ways.<br>
    </blockquote>
    Again we agree over substance; as I state elsewhere and on this
    thread, the problem is not just compile-time performance, but the
    fact that for trivial operations, you need to write a whole bunch of
    boilerplate that is unnecessary given how often serious C++ makes
    use of them. By analogy, we should not have had variadic packs in
    C++11 because the C++03 boost implementation was good enough.
    Obviously, neither Stroustrup nor Gregor (who authored the papers
    involved for C++11) agreed on NOT having parameter packs to begin
    with. It is not a question of whether packs should evolve or not,
    but when will that happen.<br>
    <br>
    I think that your conservative view is objective given its substance
    and motivation; it aims to see which solution is better. I can
    happily live with packs remaining as they are. Also I do not
    particularly care about whether language features related to packs
    as I "vision" them are to be "encouraged" or not. <i>That is not
      what I am after.</i><i><br>
    </i><br>
    What matters to is to have an adequately deep treatise of the
    problems involved as a service to the language - not for pleasing
    C++ EWG BDFLs I may have valid <i><b>technical</b></i> reasons to
    disagree with, in both substance and form of any of their
    non-arguments involved. If they just come up implementing the same
    things after some time that this is over, rehashing syntax or
    whatever else, it is not of my concern. The language will be served.
    As some of them will be :)<br>
    <br>
    Proofs by construction are more important over social networking and
    attempts to downplay any contribution by outsider volunteers.<br>
    <br>
    Regards,<br>
    <br>
    George<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&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 />

--------------010603030608060105030502--

.

--Apple-Mail=_C936BBE6-1BFE-4AE4-AFD5-01F6A83BFA34
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-18, at 1:35 AM, George Makrydakis <irrequietus@gmail.com> wrote:

> You have not altered the pack, you just used fmap-like behavior (structur=
e preserving) just as I described in a previous post by using the triple-do=
t expansion semantics (which are a language feature) and give you that 0 co=
st. Imagine doing something more meaningful like reversing the order of the=
 parameters in the pack while interleaving by inserting new types within th=
em or changing those types to other types.

That sounds contrived, not meaningful. Often I filter a pack through a unif=
orm transformation. Reversal can easily be done with make_index_sequence an=
d tuple_element, but that's not something I often need.

None of this suggests instantiating std::tuple, which is what I've been ask=
ing you about. Instantiation provides the members and layout of a class, bu=
t neither of those are interesting for std::tuple.

> Using std::tuple as a boost::mpl or boost::hana typelist construct substi=
tute is poor judgement at best.

What do you think I'm doing with tuple? It's just a way to get a handle on =
a pack.

> In the end, I think that you believe to be "right" because you are unknow=
ingly ignoring the actual context of the problems we are discussing about. =
And, tossing things out of context is a pretty pointless.

The context here is pretty narrow: when and why do you believe std::tuple g=
ets instantiated when it is used as metadata?

Either I'm right or I'm wrong. This doesn't need to be opinion-based.

--=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=_C936BBE6-1BFE-4AE4-AFD5-01F6A83BFA34
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;09&ndash;18, at 1:35 AM, George Makrydakis &lt;<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Conte=
nt-Type">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">You have not altered the pack, =
you just used fmap-like behavior
    (structure preserving) just as I described in a previous post by
    using the triple-dot expansion semantics (which are a language
    feature) and give you that 0 cost. Imagine doing something more
    meaningful like reversing the order of the parameters in the pack
    while interleaving by inserting new types within them or changing
    those types to other types.<br></div></blockquote><div><br></div><div>T=
hat sounds contrived, not meaningful. Often I filter a pack through a unifo=
rm transformation. Reversal can easily be done with <font face=3D"Courier">=
make_index_sequence</font> and <font face=3D"Courier">tuple_element</font>,=
 but that&rsquo;s not something I often need.</div><div><br></div><div>None=
 of this suggests instantiating <font face=3D"Courier">std::tuple</font>, w=
hich is what I&rsquo;ve been asking you about. Instantiation provides the m=
embers and layout of a class, but neither of those are interesting for <fon=
t face=3D"Courier">std::tuple</font>.</div><div><br></div><blockquote type=
=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">Using std::tuple as a b=
oost::mpl or boost::hana typelist construct
    substitute is poor judgement at best. </div></blockquote><div><br></div=
><div>What do you think I&rsquo;m doing with tuple? It&rsquo;s just a way t=
o get a handle on a pack.</div><br><blockquote type=3D"cite"><div text=3D"#=
000000" bgcolor=3D"#FFFFFF">In the end, I think that you believe to be "rig=
ht" because you are
    unknowingly ignoring the actual context of the problems we are
    discussing about. And, tossing things out of context is a pretty
    pointless.<br></div></blockquote><div><br></div><div>The context here i=
s pretty narrow: when and why do you believe <font face=3D"Courier">std::tu=
ple</font> gets instantiated when it is used as metadata?</div><div><br></d=
iv><div>Either I&rsquo;m right or I&rsquo;m wrong. This doesn&rsquo;t need =
to be opinion-based.</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&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 />

--Apple-Mail=_C936BBE6-1BFE-4AE4-AFD5-01F6A83BFA34--

.

I think there's just a miscommunication here, maybe? George may not be
using "instantiation" in the most precise technical definition from
the standard but rather just referring to the work the compiler does
when expanding the template in its internal type
representation/AST/whatever (which while much less work than
instantiation is still not zero work).

On Wed, Sep 17, 2014 at 11:11 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9318, at 1:35 AM, George Makrydakis <irrequietus=
@gmail.com> wrote:
>
> You have not altered the pack, you just used fmap-like behavior (structur=
e
> preserving) just as I described in a previous post by using the triple-do=
t
> expansion semantics (which are a language feature) and give you that 0 co=
st.
> Imagine doing something more meaningful like reversing the order of the
> parameters in the pack while interleaving by inserting new types within t=
hem
> or changing those types to other types.
>
>
> That sounds contrived, not meaningful. Often I filter a pack through a
> uniform transformation. Reversal can easily be done with make_index_seque=
nce
> and tuple_element, but that=E2=80=99s not something I often need.
>
> None of this suggests instantiating std::tuple, which is what I=E2=80=99v=
e been
> asking you about. Instantiation provides the members and layout of a clas=
s,
> but neither of those are interesting for std::tuple.
>
> Using std::tuple as a boost::mpl or boost::hana typelist construct
> substitute is poor judgement at best.
>
>
> What do you think I=E2=80=99m doing with tuple? It=E2=80=99s just a way t=
o get a handle on a
> pack.
>
> In the end, I think that you believe to be "right" because you are
> unknowingly ignoring the actual context of the problems we are discussing
> about. And, tossing things out of context is a pretty pointless.
>
>
> The context here is pretty narrow: when and why do you believe std::tuple
> gets instantiated when it is used as metadata?
>
> Either I=E2=80=99m right or I=E2=80=99m wrong. This doesn=E2=80=99t need =
to be opinion-based.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5QqJO73k1uI/=
unsubscribe.
> To unsubscribe from this group and all its topics, 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
Sean Middleditch
http://seanmiddleditch.com

--=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/.

.

This is a multi-part message in MIME format.
--------------090808020102020103040801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/17/2014 09:11 PM, David Krauss wrote:


[... pointless repetition ... ]
> The context here is pretty narrow: when and why do you believe
> std::tuple gets instantiated when it is used as metadata?
>
> Either I'm right or I'm wrong. This doesn't need to be opinion-based.
>
>
You are /wrong/ because you begun with the assumption that the compiler
does zero work per "instantiation", which as Sean already pointed you
towards, is definitely not true; also, you are still not avoiding the
issue of conspiratorially exploding internal representations, whether
through recursive instantiations or not, (which are a cost for people
who are just in it for the "performance" argument). When you have to do
something as simple - /and fundamental/ - with a std::tuple "hack" as a
right fold (which requires reversal, and is a catamorphism, not a
structure-preserving transformation) you become aware of this.

I also saw some confusion even when you try to put "instantiation" into
context since you are wildly crossing the limit into /object
instantiation/ which is another thing. Do remember that function
templates have "instantiations" too, which are not of the nature you
describe:

http://en.cppreference.com/w/cpp/language/function_template

Another thing is that the standard itself has no notion of "metadata",
or "metaprocessing", nor are these terms used in any C++ template
meta-programming grounds. I consider even "compile-time" abusive since
the notion in the standard is that of a "translation unit". And
/different translation units/ with /different internal representations/
added to your code for function / class template instantiations have a
very real, non-zero cost C++ compiler implementers are very much aware
of. As are the compile times for said code.

But all of this is "taxonomy" as you usually say. I already sent a reply
to Sean's email (who is right) and waiting for dear Google Groups to
have it up in these forums.

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/.

--------------090808020102020103040801
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/17/2014 09:11 PM, David Krauss
      wrote:<br>
      <br>
      <br>
      [... pointless repetition ... ]<br>
    </div>
    <blockquote
      cite="mid:1D1E0B7E-9A86-4891-B5CA-A8A86D2B21B2@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div>
        <div>The context here is pretty narrow: when and why do you
          believe <font face="Courier">std::tuple</font> gets
          instantiated when it is used as metadata?</div>
        <div><br>
        </div>
        <div>Either I&rsquo;m right or I&rsquo;m wrong. This doesn&rsquo;t need to be
          opinion-based.</div>
        <div><br>
        </div>
      </div>
      <br>
    </blockquote>
    You are <i>wrong</i> because you begun with the assumption that the
    compiler does zero work per "instantiation", which as Sean already
    pointed you towards, is definitely not true; also, you are still not
    avoiding the issue of conspiratorially exploding internal
    representations, whether through recursive instantiations or not,
    (which are a cost for people who are just in it for the
    "performance" argument). When you have to do something as simple - <i>and
      fundamental</i> - with a std::tuple "hack" as a right fold (which
    requires reversal, and is a catamorphism, not a structure-preserving
    transformation) you become aware of this.<br>
    <br>
    I also saw some confusion even when you try to put "instantiation"
    into context since you are wildly crossing the limit into <i>object
      instantiation</i> which is another thing. Do remember that
    function templates have "instantiations" too, which are not of the
    nature you describe:<br>
    <br>
    <a
      href="http://en.cppreference.com/w/cpp/language/function_template">http://en.cppreference.com/w/cpp/language/function_template</a><br>
    <br>
    Another thing is that the standard itself has no notion of
    "metadata", or "metaprocessing", nor are these terms used in any C++
    template meta-programming grounds. I consider even "compile-time"
    abusive since the notion in the standard is that of a "translation
    unit". And <i>different translation units</i> with <i>different
      internal representations</i> added to your code for function /
    class template instantiations have a very real, non-zero cost C++
    compiler implementers are very much aware of. As are the compile
    times for said code.<br>
    <br>
    But all of this is "taxonomy" as you usually say. I already sent a
    reply to Sean's email (who is right) and waiting for dear Google
    Groups to have it up in these forums.<br>
    <br>
    George<br>
    <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&quot; 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 />

--------------090808020102020103040801--

.

------=_Part_230_1017881676.1410982947859
Content-Type: text/plain; charset=UTF-8



On Wednesday, September 17, 2014 10:39:53 PM UTC+3, George Makrydakis wrote:
>
>
> conspiratorially
>
>
combinatorially

--

---
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_230_1017881676.1410982947859
Content-Type: text/html; charset=UTF-8

<div dir="ltr"><br><br>On Wednesday, September 17, 2014 10:39:53 PM UTC+3, George Makrydakis wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">



  <div text="#000000" bgcolor="#FFFFFF">
    <br>conspiratorially <br>
    <br></div></blockquote><div><br>combinatorially<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&quot; 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_230_1017881676.1410982947859--

.

--Apple-Mail=_CB2FA58C-3C6C-4F6A-844B-16EFBCB10FBF
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-18, at 3:41 AM, George Makrydakis <irrequietus@gmail.com> wrote:

> You are wrong because you begun with the assumption that the compiler does zero work per "instantiation",

I never said zero work per instantiation, I said zero instantiations.

> which as Sean already pointed you towards,

Sean suggested that you're not using "the most precise technical definition from the standard," and as far as I'm concerned, if you can't do that, you don't even know what an instantiation is.

Please learn the standard terminology. Good day.

--

---
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/.

--Apple-Mail=_CB2FA58C-3C6C-4F6A-844B-16EFBCB10FBF
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;09&ndash;18, at 3:41 AM, George Makrydakis &lt;<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Conte=
nt-Type">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">You are <i>wrong</i> because yo=
u begun with the assumption that the
    compiler does zero work per "instantiation&rdquo;,</div></blockquote><d=
iv><br></div><div>I never said zero work per instantiation, I said zero ins=
tantiations.</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcol=
or=3D"#FFFFFF"> which as Sean already
    pointed you towards, </div></blockquote><div><br></div><div>Sean sugges=
ted that you&rsquo;re not using "the most precise technical definition from=
 the standard,&rdquo; and as far as I&rsquo;m concerned, if you can&rsquo;t=
 do that, you don&rsquo;t even know what an instantiation is.</div><div><br=
></div><div>Please learn the standard terminology. Good day.</div></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&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 />

--Apple-Mail=_CB2FA58C-3C6C-4F6A-844B-16EFBCB10FBF--

.

------=_Part_1068_858410534.1410985454945
Content-Type: text/plain; charset=UTF-8

Sorry for the delayed reply.

> On Wednesday, 17 September 2014 11:41:11 UTC-4, George Makrydakis wrote:
>
> On 09/16/2014 04:12 AM, Louis Dionne wrote:
> >
> > Based on the experience of writing Boost.Hana, my opinion is that we do
not
> > want a better support for parameter packs, at least not "officially".
Let me
> > explain.
>
> Based on my own experience of writing several different libraries like
> boost::mpl, boost::hana and boost::preprocessor, doing recursive
> instantiations for trivial pack processing or relying on muddy compiler
> intrinsics for efficient compile-time big-O results is something that is
> going to bite you back in the end. So, we need official support. And
isn't
> EWG#30 active for 2+ years just for this?

I don't see why that would bite me back in the end if the compile-time
performance is OK. Are you referring to maintenance cost or even something
else? Also, since you seem to have done some extensive work on the subject,
were those metaprogramming projects you mentioned open source? If so, I'd
like to take a look; I'm always looking for ways to improve Hana.


> > Parameter packs do not compose very well because they are not a single
entity,
> > and they are bound to express something isomorphic (via hand waving) to
> > std::tuple. However, there are several other data structures that are
useful
> > when metaprogramming. For example, one could imagine a tree containing
> > heterogeneous objects, which could be useful for expression templates.
>
> Parameter packs do not compose very well because they are second-class
> citizens in a template parameter list, where anything practical has to be
> done through recursive template instantiations, including something as
> trivial as index/range-based access.

The view of things I wanted to express is that once you get some really nice
and complete interface for parameter packs, will you try adding "tree-like"
parameter packs to the language? Assuming you don't, you will most likely
come up with a library approach providing a std::tuple-like structure that
represents a tree.

Now, since parameter packs are basically tuples, why treat them as a
special
case and provide a special syntax? If we disregard compile-time performance
(which can be handled either way), it seems to me that the library-based
approach is more consistent.

> [...]
>
> This aspect of the triple-dot is even exploited by concepts in order to
work
> with parameter packs. And yet, we have to resort into recursive template
> instantiations for even accessing an individual parameter. Worse, we
cannot
> even do structure-preserving transformations over a range of indexes
within
> the pack without using recursive template instantiations. We should only
use
> such recursive instantiations when meaningful catamorphisms are in play,
not
> for accessing a parameter or a range of parameters within known indices!
To
> cite Shakespeare in good will, "something is rotten in the state of
Denmark".

Those statements about the need for recursive instantiations are true in a
formal way, but they are not really useful given that we're trying to get a
decent compile-time performance. I already posted how to fetch an element
at
a random index without recursion (modulo `std::index_sequence`), and here's
a
metafunction that maps another metafunction over a subrange of a parameter
pack without recursive instantiations (modulo `std::index_sequence`):

```cpp
    template <typename ...>
    struct type_list { };

    template <bool condition, template <typename ...> class f, typename x>
    struct apply_if { using type = typename f<x>::type; };

    template <template <typename ...> class f, typename x>
    struct apply_if<false, f, x> { using type = x; };

    template <
        std::size_t from, std::size_t to,
        template <typename ...> class f,
        typename ...xs,
        std::size_t ...i
    >
    type_list<typename apply_if<(from <= i && i < to), f, xs>::type...>
    fmap_subrange_impl(type_list<xs...>, std::index_sequence<i...>);

    template <
        std::size_t from, std::size_t to,
        template <typename ...> class f,
        typename ...xs
    >
    using fmap_subrange_t = decltype(
        fmap_subrange_impl<from, to, f>(
            type_list<xs...>{},
            std::make_index_sequence<sizeof...(xs)>{}
        )
    );

    static_assert(
        std::is_same<
            fmap_subrange_t<
                2, 4, std::add_pointer, int, char, float, double, void
            >,
            type_list<int, char, float*, double*, void>
        >::value
    , "");
```

Now, of course we need recursion inside `std::make_index_sequence`, but
that
cost is amortized over many uses of the metafunction. Also, benchmarking
shows
that instantiating even large `std::integer_sequence`s is not a problem.
You
could still raise an objection about the use of `apply_if`, which is
instantiated N times (albeit not recursively). There's no perfect solution,
but we can use the following instead, which is less costly because
(according
to benchmarks) template aliases are cheaper than full structs:

```cpp
    template <bool condition, template <typename ...> class f>
    struct apply_if {
        template <typename x> using result = x;
    };

    template <template <typename ...> class f>
    struct apply_if<true, f> {
        template <typename x> using result = typename f<x>::type;
    };

    template <
        std::size_t from, std::size_t to,
        template <typename ...> class f,
        typename ...xs,
        std::size_t ...i
    >
    type_list<typename apply_if<(from <= i && i < to), f>::template
result<xs>...>
    fmap_subrange_impl(type_list<xs...>, std::index_sequence<i...>);

    // same as before...
```

I don't intend end-users to write this code; but I would expect a
well-written
library to use these techniques instead of naive recursive instantiations.

> [...]

All that being said, if you give me a more efficient way to access
individual
parameter packs (or ranges thereof), then I'll simply use it as if it were a
compiler intrinsic inside the implementation of other data structures with
a higher level interface. So you'd really be making my life easier and my
library better, which I am definitely not opposed to.

Also, I'd like to point out that fixing parameter packs won't do it all
for compile-time performance. Instantiating a `std::tuple` has a huge
compile-time cost, even if you never use `std::get`; but that's another
story.

Regards,
Louis

--

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

<div dir=3D"ltr"><div>Sorry for the delayed reply.</div><div><br></div><div=
>&gt; On Wednesday, 17 September 2014 11:41:11 UTC-4, George Makrydakis wro=
te:</div><div>&gt;&nbsp;</div><div>&gt; On 09/16/2014 04:12 AM, Louis Dionn=
e wrote:</div><div>&gt; &gt;</div><div>&gt; &gt; Based on the experience of=
 writing Boost.Hana, my opinion is that we do not</div><div>&gt; &gt; want =
a better support for parameter packs, at least not "officially". Let me</di=
v><div>&gt; &gt; explain.</div><div>&gt;&nbsp;</div><div>&gt; Based on my o=
wn experience of writing several different libraries like&nbsp;</div><div>&=
gt; boost::mpl, boost::hana and boost::preprocessor, doing recursive&nbsp;<=
/div><div>&gt; instantiations for trivial pack processing or relying on mud=
dy compiler&nbsp;</div><div>&gt; intrinsics for efficient compile-time big-=
O results is something that is&nbsp;</div><div>&gt; going to bite you back =
in the end. So, we need official support. And isn't&nbsp;</div><div>&gt; EW=
G#30 active for 2+ years just for this?</div><div><br></div><div>I don't se=
e why that would bite me back in the end if the compile-time&nbsp;</div><di=
v>performance is OK. Are you referring to maintenance cost or even somethin=
g</div><div>else? Also, since you seem to have done some extensive work on =
the subject,</div><div>were those metaprogramming projects you mentioned op=
en source? If so, I'd&nbsp;</div><div>like to take a look; I'm always looki=
ng for ways to improve Hana.</div><div><br></div><div><br></div><div>&gt; &=
gt; Parameter packs do not compose very well because they are not a single =
entity,</div><div>&gt; &gt; and they are bound to express something isomorp=
hic (via hand waving) to</div><div>&gt; &gt; std::tuple. However, there are=
 several other data structures that are useful</div><div>&gt; &gt; when met=
aprogramming. For example, one could imagine a tree containing&nbsp;</div><=
div>&gt; &gt; heterogeneous objects, which could be useful for expression t=
emplates.</div><div>&gt;&nbsp;</div><div>&gt; Parameter packs do not compos=
e very well because they are second-class&nbsp;</div><div>&gt; citizens in =
a template parameter list, where anything practical has to be&nbsp;</div><d=
iv>&gt; done through recursive template instantiations, including something=
 as&nbsp;</div><div>&gt; trivial as index/range-based access.</div><div><br=
></div><div>The view of things I wanted to express is that once you get som=
e really nice</div><div>and complete interface for parameter packs, will yo=
u try adding "tree-like"</div><div>parameter packs to the language? Assumin=
g you don't, you will most likely</div><div>come up with a library approach=
 providing a std::tuple-like structure that</div><div>represents a tree.</d=
iv><div><br></div><div>Now, since parameter packs are basically tuples, why=
 treat them as a special&nbsp;</div><div>case and provide a special syntax?=
 If we disregard compile-time performance&nbsp;</div><div>(which can be han=
dled either way), it seems to me that the library-based&nbsp;</div><div>app=
roach is more consistent.</div><div><br></div><div>&gt; [...]</div><div>&gt=
;&nbsp;</div><div>&gt; This aspect of the triple-dot is even exploited by c=
oncepts in order to work&nbsp;</div><div>&gt; with parameter packs. And yet=
, we have to resort into recursive template&nbsp;</div><div>&gt; instantiat=
ions for even accessing an individual parameter. Worse, we cannot&nbsp;</di=
v><div>&gt; even do structure-preserving transformations over a range of in=
dexes within&nbsp;</div><div>&gt; the pack without using recursive template=
 instantiations. We should only use</div><div>&gt; such recursive instantia=
tions when meaningful catamorphisms are in play, not&nbsp;</div><div>&gt; f=
or accessing a parameter or a range of parameters within known indices! To&=
nbsp;</div><div>&gt; cite Shakespeare in good will, "something is rotten in=
 the state of Denmark".</div><div><br></div><div>Those statements about the=
 need for recursive instantiations are true in a</div><div>formal way, but =
they are not really useful given that we're trying to get a&nbsp;</div><div=
>decent compile-time performance. I already posted how to fetch an element =
at&nbsp;</div><div>a random index without recursion (modulo `std::index_seq=
uence`), and here's a&nbsp;</div><div>metafunction that maps another metafu=
nction over a subrange of a parameter&nbsp;</div><div>pack without recursiv=
e instantiations (modulo `std::index_sequence`):</div><div><br></div><div>`=
``cpp</div><div>&nbsp; &nbsp; template &lt;typename ...&gt;</div><div>&nbsp=
; &nbsp; struct type_list { };</div><div><br></div><div>&nbsp; &nbsp; templ=
ate &lt;bool condition, template &lt;typename ...&gt; class f, typename x&g=
t;</div><div>&nbsp; &nbsp; struct apply_if { using type =3D typename f&lt;x=
&gt;::type; };</div><div><br></div><div>&nbsp; &nbsp; template &lt;template=
 &lt;typename ...&gt; class f, typename x&gt;</div><div>&nbsp; &nbsp; struc=
t apply_if&lt;false, f, x&gt; { using type =3D x; };</div><div><br></div><d=
iv>&nbsp; &nbsp; template &lt;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; std::s=
ize_t from, std::size_t to,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; template =
&lt;typename ...&gt; class f,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; typenam=
e ...xs,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; std::size_t ...i</div><div>&=
nbsp; &nbsp; &gt;</div><div>&nbsp; &nbsp; type_list&lt;typename apply_if&lt=
;(from &lt;=3D i &amp;&amp; i &lt; to), f, xs&gt;::type...&gt;</div><div>&n=
bsp; &nbsp; fmap_subrange_impl(type_list&lt;xs...&gt;, std::index_sequence&=
lt;i...&gt;);</div><div><br></div><div>&nbsp; &nbsp; template &lt;</div><di=
v>&nbsp; &nbsp; &nbsp; &nbsp; std::size_t from, std::size_t to,</div><div>&=
nbsp; &nbsp; &nbsp; &nbsp; template &lt;typename ...&gt; class f,</div><div=
>&nbsp; &nbsp; &nbsp; &nbsp; typename ...xs</div><div>&nbsp; &nbsp; &gt;</d=
iv><div>&nbsp; &nbsp; using fmap_subrange_t =3D decltype(</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp; fmap_subrange_impl&lt;from, to, f&gt;(</div><div>&nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; type_list&lt;xs...&gt;{},</div><div>&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; std::make_index_sequence&lt;sizeof.=
...(xs)&gt;{}</div><div>&nbsp; &nbsp; &nbsp; &nbsp; )</div><div>&nbsp; &nbsp=
; );</div><div><br></div><div>&nbsp; &nbsp; static_assert(</div><div>&nbsp;=
 &nbsp; &nbsp; &nbsp; std::is_same&lt;</div><div>&nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; fmap_subrange_t&lt;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; 2, 4, std::add_pointer, int, char, float, double=
, void</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &gt;,</div><div>=
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; type_list&lt;int, char, float*, d=
ouble*, void&gt;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &gt;::value</div><di=
v>&nbsp; &nbsp; , "");</div><div>```</div><div><br></div><div>Now, of cours=
e we need recursion inside `std::make_index_sequence`, but that&nbsp;</div>=
<div>cost is amortized over many uses of the metafunction. Also, benchmarki=
ng shows&nbsp;</div><div>that instantiating even large `std::integer_sequen=
ce`s is not a problem. You&nbsp;</div><div>could still raise an objection a=
bout the use of `apply_if`, which is&nbsp;</div><div>instantiated N times (=
albeit not recursively). There's no perfect solution,&nbsp;</div><div>but w=
e can use the following instead, which is less costly because (according&nb=
sp;</div><div>to benchmarks) template aliases are cheaper than full structs=
:</div><div><br></div><div>```cpp</div><div>&nbsp; &nbsp; template &lt;bool=
 condition, template &lt;typename ...&gt; class f&gt;</div><div>&nbsp; &nbs=
p; struct apply_if {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; template &lt;typ=
ename x&gt; using result =3D x;</div><div>&nbsp; &nbsp; };</div><div><br></=
div><div>&nbsp; &nbsp; template &lt;template &lt;typename ...&gt; class f&g=
t;</div><div>&nbsp; &nbsp; struct apply_if&lt;true, f&gt; {</div><div>&nbsp=
; &nbsp; &nbsp; &nbsp; template &lt;typename x&gt; using result =3D typenam=
e f&lt;x&gt;::type;</div><div>&nbsp; &nbsp; };</div><div><br></div><div>&nb=
sp; &nbsp; template &lt;</div><div>&nbsp; &nbsp; &nbsp; &nbsp; std::size_t =
from, std::size_t to,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; template &lt;ty=
pename ...&gt; class f,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; typename ...x=
s,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; std::size_t ...i</div><div>&nbsp; =
&nbsp; &gt;</div><div>&nbsp; &nbsp; type_list&lt;typename apply_if&lt;(from=
 &lt;=3D i &amp;&amp; i &lt; to), f&gt;::template result&lt;xs&gt;...&gt;</=
div><div>&nbsp; &nbsp; fmap_subrange_impl(type_list&lt;xs...&gt;, std::inde=
x_sequence&lt;i...&gt;);</div><div><br></div><div>&nbsp; &nbsp; // same as =
before...</div><div>```</div><div><br></div><div>I don't intend end-users t=
o write this code; but I would expect a well-written</div><div>library to u=
se these techniques instead of naive recursive instantiations.</div><div><b=
r></div><div>&gt; [...]</div><div><br></div><div>All that being said, if yo=
u give me a more efficient way to access individual</div><div>parameter pac=
ks (or ranges thereof), then I'll simply use it as if it were a</div><div>c=
ompiler intrinsic inside the implementation of other data structures with&n=
bsp;</div><div>a higher level interface. So you'd really be making my life =
easier and my&nbsp;</div><div>library better, which I am definitely not opp=
osed to.</div><div><br></div><div>Also, I'd like to point out that fixing p=
arameter packs won't do it all&nbsp;</div><div>for compile-time performance=
.. Instantiating a `std::tuple` has a huge&nbsp;</div><div>compile-time cost=
, even if you never use `std::get`; but that's another&nbsp;</div><div>stor=
y.</div><div><br></div><div>Regards,</div><div>Louis</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&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_1068_858410534.1410985454945--

.

------=_Part_1127_991714154.1410985543856
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, September 17, 2014 10:52:06 PM UTC+3, David Krauss wrote:
>
>
> On 2014=E2=80=9309=E2=80=9318, at 3:41 AM, George Makrydakis <irreq...@gm=
ail.com=20
> <javascript:>> wrote:
>
>
> Sean suggested that you=E2=80=99re not using "the most precise technical=
=20
> definition from the standard,=E2=80=9D and as far as I=E2=80=99m concerne=
d, if you can=E2=80=99t do=20
> that, you don=E2=80=99t even know what an instantiation is.
>


Taking things out of context suits you fine. It is obvious to even Jar Jar=
=20
Binks C++ programmers that *you* started implying zero instantiation *work*=
=20
while thinking about *object instantiation *cost. Function template=20
instantiations for example, are NOT about *object instantiations*. You have=
=20
the ideas mixed up because you ignore "taxonomy" because you ignore C++=20
meta-programming fundamentals (as well as things like context deducibility=
=20
in the standard itself).
=20

>
> Please learn the standard terminology. Good day.
>
>

Once you find where "metadata", "metaprocessing" and "function template=20
instantiations and member functions" (for christ's sake...) as is=20
consequential from your "instantiation" definition are *not* found, you=20
will be able to understand what the standards says and what does not. Also=
=20
bear in mind that when dealing with "template instantiations", any compiler=
=20
implementer will be including the cost of the internal representation, *to=
=20
which you are completely* *oblivious* about. Given the multiple times you=
=20
have been in complete error with other list posters and your obvious mishap=
=20
on multiple parameter packs, ignorance of decades of research on what=20
catamorphisms and anamorphisms are (dismissing them as "taxonomy" in your=
=20
other posts), I'd take your baseless and repeated ad-hominem as a poor=20
attempt at sounding authoritative. You are clearly not.

I wish you *good night*, you seem to be fully immersed in it and will be=20
for some time. Stop twisting real contributions into offtopicness in order=
=20
to comply with your self-appointed expert opinion, one could have some use=
=20
for as an example to avoid. You have no actual perception of what we are=20
discussing here. Addressing *you* because you are *noisy poster* is a waste=
=20
of time.

Just because some of *your* ignorance resorts into ad-hominem for its=20
defense, don't think that *your* nonsense won't be addressed without=20
pointing that out. Come back when you have anything valid to contribute.

George

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

<div dir=3D"ltr"><br><br>On Wednesday, September 17, 2014 10:52:06 PM UTC+3=
, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div styl=
e=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9309=E2=80=9318, at =
3:41 AM, George Makrydakis &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"MnD-S5QLiwQJ" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq..=
..@gmail.com</a>&gt; wrote:</div><br><br><div>Sean suggested that you=E2=80=
=99re not using "the most precise technical definition from the standard,=
=E2=80=9D and as far as I=E2=80=99m concerned, if you can=E2=80=99t do that=
, you don=E2=80=99t even know what an instantiation is.</div></div></div></=
blockquote><div><br><br>Taking things out of context suits you fine. It is =
obvious to even Jar Jar Binks C++ programmers that <i>you</i> started imply=
ing zero instantiation <i>work</i> while thinking about <i>object instantia=
tion </i>cost. Function template instantiations for example, are NOT about =
<i>object instantiations</i>. You have the ideas mixed up because you ignor=
e "taxonomy" because you ignore C++ meta-programming fundamentals (as well =
as things like context deducibility in the standard itself).<br>&nbsp;<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><div><div><br></div><div>Please learn the standard terminology. =
Good day.</div></div><br></div></blockquote><div><br><br>Once you find wher=
e "metadata", "metaprocessing" and "function template instantiations and me=
mber functions" (for christ's sake...) as is consequential from your "insta=
ntiation" definition are <i>not</i> found, you will be able to understand w=
hat the standards says and what does not. Also bear in mind that when deali=
ng with "template instantiations", any compiler implementer will be includi=
ng the cost of the internal representation, <i>to which you are completely<=
/i> <i>oblivious</i> about. Given the multiple times you have been in compl=
ete error with other list posters and your obvious mishap on multiple param=
eter packs, ignorance of decades of research on what catamorphisms and anam=
orphisms are (dismissing them as "taxonomy" in your other posts), I'd take =
your baseless and repeated ad-hominem as a poor attempt at sounding authori=
tative. You are clearly not.<br><br>I wish you <b><i>good night</i></b>, yo=
u seem to be fully immersed in it and will be for some time. Stop twisting =
real contributions into offtopicness in order to comply with your self-appo=
inted expert opinion, one could have some use for as an example to avoid. Y=
ou have no actual perception of what we are discussing here. Addressing <i>=
you</i> because you are <i>noisy poster</i> is a waste of time.<br><br>Just=
 because some of <i>your</i> ignorance resorts into ad-hominem for its defe=
nse, don't think that <i>your</i> nonsense won't be addressed without point=
ing that out. Come back when you have anything valid to contribute.<br><br>=
George<br><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&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_1127_991714154.1410985543856--

.

------=_Part_1009_350326114.1410987000352
Content-Type: text/plain; charset=UTF-8



On Wednesday, September 17, 2014 11:24:15 PM UTC+3, Louis Dionne wrote:
>
> Sorry for the delayed reply.
>
>
[... lots of good and correct stuff but I will get to his concluding
remarks because they are the essence of what we are discussing about ...]


> All that being said, if you give me a more efficient way to access
> individual
> parameter packs (or ranges thereof), then I'll simply use it as if it were
> a
> compiler intrinsic inside the implementation of other data structures with
> a higher level interface. So you'd really be making my life easier and my
> library better, which I am definitely not opposed to.
>

Then we agree over substance. Annotated template parameter packs are about
offering you a way to have such efficient access. Same is with Sean's
typelist access. And with all the work people are trying to do for packs,
regardless of who is doing it. So I do not see us disagreeing over
substance or the contents of things like EWG#30 being resolved as a
language feature. I think that a lot of the boilerplate and compile-time
cost required for using libraries like boost::mpl, boost::hana (and others).


>
> Also, I'd like to point out that fixing parameter packs won't do it all
> for compile-time performance. Instantiating a `std::tuple` has a huge
> compile-time cost, even if you never use `std::get`; but that's another
> story.
>
>
Indeed, I am not for "fixing parameter packs", I am for extending their
semantics for offering you easy tools you require for making great
libraries even better; remember that EWG#30 was inspired by a notorious
template meta-programmer. As for compile-time performance, std::tuple
instantiations have a definite compile-time cost people like David Krauss
seem to be totally ignoring. Perhaps we should all explain that "each
template instantiation has an internal representation cost that goes out of
linear penalties when meta-programming is involved". It takes a serious
compiler implementer and/or a serious benchmarker (like you and your good
work done with it in boost::hana) to understand such issues. The main
motivation behind expanding pack semantics is not "compile-time
performance", but primarily about reducing boilerplate and the need of
compiler-bound "dirty tricks". By analogy, I am simply following the path
that brought us decltype, auto, variadics and other awesome stuff that made
our life easier. Same thing Sean does (as well as others). I think we all
want that.

Unrelated to you, I really do not see the *technical* reason for the
passion with which certain people, attack others because the contributions
of the latter do not fit with the social powerplay agendas of the former. I
thought that these grounds (and the standards committee) were here for
technical discussions. My experience so far, is one of disillusionment for
the most part. There is a use for such a paper trail as well.

Regards,

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/.

------=_Part_1009_350326114.1410987000352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 17, 2014 11:24:15 PM UTC+3=
, Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Sorry for the delayed reply.</div><br></div></blockquote><div=
>&nbsp;</div><div>[... lots of good and correct stuff but I will get to his=
 concluding remarks because they are the essence of what we are discussing =
about ...]<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>All that being said, if you give me a more efficient =
way to access individual</div><div>parameter packs (or ranges thereof), the=
n I'll simply use it as if it were a</div><div>compiler intrinsic inside th=
e implementation of other data structures with&nbsp;</div><div>a higher lev=
el interface. So you'd really be making my life easier and my&nbsp;</div><d=
iv>library better, which I am definitely not opposed to.</div></div></block=
quote><div><br>Then we agree over substance. Annotated template parameter p=
acks are about offering you a way to have such efficient access. Same is wi=
th Sean's typelist access. And with all the work people are trying to do fo=
r packs, regardless of who is doing it. So I do not see us disagreeing over=
 substance or the contents of things like EWG#30 being resolved as a langua=
ge feature. I think that a lot of the boilerplate and compile-time cost req=
uired for using libraries like boost::mpl, boost::hana (and others).<br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><br></div><div>Also, I'd like to point out that fixing parameter packs won=
't do it all&nbsp;</div><div>for compile-time performance. Instantiating a =
`std::tuple` has a huge&nbsp;</div><div>compile-time cost, even if you neve=
r use `std::get`; but that's another&nbsp;</div><div>story.</div><div><br><=
/div></div></blockquote><div><br>Indeed, I am not for "fixing parameter pac=
ks", I am for extending their semantics for offering you easy tools you req=
uire for making great libraries even better; remember that EWG#30 was inspi=
red by a notorious template meta-programmer. As for compile-time performanc=
e, std::tuple instantiations have a definite compile-time cost people like =
David Krauss seem to be totally ignoring. Perhaps we should all explain tha=
t "each template instantiation has an internal representation cost that goe=
s out of linear penalties when meta-programming is involved". It takes a se=
rious compiler implementer and/or a serious benchmarker (like you and your =
good work done with it in boost::hana) to understand such issues. The main =
motivation behind expanding pack semantics is not "compile-time performance=
", but primarily about reducing boilerplate and the need of compiler-bound =
"dirty tricks". By analogy, I am simply following the path that brought us =
decltype, auto, variadics and other awesome stuff that made our life easier=
.. Same thing Sean does (as well as others). I think we all want that.<br><b=
r>Unrelated to you, I really do not see the <i>technical</i> reason for the=
 passion with which certain people, attack others because the contributions=
 of the latter do not fit with the social powerplay agendas of the former. =
I thought that these grounds (and the standards committee) were here for te=
chnical discussions. My experience so far, is one of disillusionment for th=
e most part. There is a use for such a paper trail as well.<br><br></div><d=
iv>Regards,<br><br>George <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&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_1009_350326114.1410987000352--

.

------=_Part_783_40650840.1410987114920
Content-Type: text/plain; charset=UTF-8



On Wednesday, September 17, 2014 11:50:00 PM UTC+3, George Makrydakis wrote:
[...]

> Then we agree over substance. Annotated template parameter packs are about
> offering you a way to have such efficient access. Same is with Sean's
> typelist access. And with all the work people are trying to do for packs,
> regardless of who is doing it. So I do not see us disagreeing over
> substance or the contents of things like EWG#30 being resolved as a
> language feature. I think that a lot of the boilerplate and compile-time
> cost required for using libraries like boost::mpl, boost::hana (and others).
>
>

.... could be substantially lowered by expanding pack semantics.

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/.

------=_Part_783_40650840.1410987114920
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 17, 2014 11:50:00 PM UTC+3=
, George Makrydakis wrote:<div>[...] <br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>Then we agree over substance. Annota=
ted template parameter packs are about offering you a way to have such effi=
cient access. Same is with Sean's typelist access. And with all the work pe=
ople are trying to do for packs, regardless of who is doing it. So I do not=
 see us disagreeing over substance or the contents of things like EWG#30 be=
ing resolved as a language feature. I think that a lot of the boilerplate a=
nd compile-time cost required for using libraries like boost::mpl, boost::h=
ana (and others).<br>&nbsp;</div></div></blockquote><div><br>... could be s=
ubstantially lowered by expanding pack semantics.<br><br>George <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&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_783_40650840.1410987114920--

.

------=_Part_3569_541163361.1411225428307
Content-Type: text/plain; charset=UTF-8

George & David, are we here to try and improve C++ or to criticise each
other?

--

---
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_3569_541163361.1411225428307
Content-Type: text/html; charset=UTF-8

<div dir="ltr">George &amp; David, are we here to try and improve C++ or to criticise each other?<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&quot; 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_3569_541163361.1411225428307--

.

--Apple-Mail=_7C4B9BC9-F897-4F63-9B6E-E39D5180D5FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-20, at 11:03 PM, Douglas Boffey <douglas.boffey@gmail.com> wrote=
:

> George & David, are we here to try and improve C++ or to criticise each o=
ther?

If we're going to work together to improve C++, we all have to agree on ter=
minology. "Instantiation" has a particular definition, and George's claim t=
hat std::tuple<void, int()> carries instantiation cost doesn't fit it, beca=
use that specialization cannot be instantiated.

He seems to think that others should intuitively grasp his argument, no mat=
ter if it's phrased in alternate, personal definitions of well-defined word=
s. I'd love to know what he's trying to say, but it's not looking likely.

I just hope that any readers won't be misled: std::tuple is as viable as a =
dedicated empty or undefined class template, because metaprocessing does no=
t need to invoke instantiation of such a type-list handle.

The compilation cost of putting "std::tuple" in front of a type-list is mer=
ely that of having the type-list, and a pointer to the tuple primary templa=
te. This is, as I claimed, "essentially zero work for the compiler." Having=
 some grammar for a type-list not bound to a template-name would not provid=
e much memory savings or performance boost.

I believe that tuple viability has a bearing on improving C++. I haven't sa=
id anything about ATPP. George seems quite focused on his proposal, but I n=
ever made any claim with any bearing on ATPP.

Whatever ATPP does, metaprograms written in it still have inputs, outputs, =
and intermediate results. It's a deterministic system, not as radical as sa=
y Prolog. All data still need to be represented as argument lists bound to =
metafunctions, or argument lists bound to things that aren't metafunctions.=
 Perhaps his system promotes lazy evaluation such that more intermediate re=
sults involve unevaluated metafunctions... but from the look of it, it's no=
t that radical either. It looks more like a shorthand for list slice and sp=
lice operations (which may be equally fast as a library facility), plus siz=
e constraints (which Concepts Lite already does). So, ATPP doesn't look lik=
ely to have different performance characteristics from anything else.

Anyway, let's focus on clarity and convenience and let implementers worry a=
bout compile times.

--=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=_7C4B9BC9-F897-4F63-9B6E-E39D5180D5FC
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;09&ndash;20, at 11:03 PM, Douglas Boffey &lt;<a href=3D"mailto:dougla=
s.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt; wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">G=
eorge &amp; David, are we here to try and improve C++ or to criticise each =
other?<br></div></blockquote><br></div><div>If we&rsquo;re going to work to=
gether to improve C++, we all have to agree on terminology. &ldquo;Instanti=
ation&rdquo; has a particular definition, and George&rsquo;s claim that <fo=
nt face=3D"Courier">std::tuple&lt;void, int()&gt;</font>&nbsp;carries insta=
ntiation cost doesn&rsquo;t fit it, because that specialization cannot be i=
nstantiated.</div><div><br></div><div>He seems to think that others should =
intuitively grasp his argument, no matter if it&rsquo;s phrased in alternat=
e, personal definitions of well-defined words. I&rsquo;d love to know what =
he&rsquo;s trying to say, but it&rsquo;s not looking likely.</div><div><br>=
</div><div>I just hope that any readers won&rsquo;t be misled: <font face=
=3D"Courier">std::tuple</font> is as viable as a dedicated empty or undefin=
ed class template, because metaprocessing does not need to invoke instantia=
tion of such a type-list handle.</div><div><br></div><div>The compilation c=
ost of putting &ldquo;<font face=3D"Courier">std::tuple</font>&rdquo; in fr=
ont of a type-list is merely that of having the type-list, and a pointer to=
 the <font face=3D"Courier">tuple</font> primary template. This is, as I cl=
aimed, &ldquo;essentially zero work for the compiler.&rdquo; Having some gr=
ammar for a type-list not bound to a template-name would not provide much m=
emory savings or performance boost.</div><div><br></div><div>I believe that=
 <font face=3D"Courier">tuple</font> viability has a bearing on improving C=
++. I haven&rsquo;t said anything about ATPP. George seems quite focused on=
 his proposal, but I never made any claim with any bearing on ATPP.</div><d=
iv><br></div><div>Whatever ATPP does, metaprograms written in it still have=
 inputs, outputs, and intermediate results. It&rsquo;s a deterministic syst=
em, not as radical as say Prolog. All data still need to be represented as =
argument lists bound to metafunctions, or argument lists bound to things th=
at aren&rsquo;t metafunctions. Perhaps his system promotes lazy evaluation =
such that more intermediate results involve unevaluated metafunctions&helli=
p; but from the look of it, it&rsquo;s not that radical either. It looks mo=
re like a shorthand for list slice and splice operations (which may be equa=
lly fast as a library facility), plus size constraints (which Concepts Lite=
 already does). So, ATPP doesn&rsquo;t look likely to have different perfor=
mance characteristics from anything else.</div><div><br></div><div>Anyway, =
let&rsquo;s focus on clarity and convenience and let implementers worry abo=
ut compile times.</div><div><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&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 />

--Apple-Mail=_7C4B9BC9-F897-4F63-9B6E-E39D5180D5FC--

.

This is a multi-part message in MIME format.
--------------050305040907040602060304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 09/20/2014 08:43 PM, David Krauss wrote:
>
> On 2014-09-20, at 11:03 PM, Douglas Boffey <douglas.boffey@gmail.com
> <mailto:douglas.boffey@gmail.com>> wrote:
>
>> George & David, are we here to try and improve C++ or to criticise
>> each other?
>
> If we're going to work together to improve C++, we all have to agree
> on terminology. "Instantiation" has a particular definition, and
> George's claim that std::tuple<void, int()> carries instantiation cost
> doesn't fit it, because that specialization cannot be instantiated.
>
>

Regarding function and class template instantiation, one has to
understand that the standard provides no description of the internal
mechanics of instantiation representation, which is left to the mercy of
the quality of people involved in a particular implementation. This is
why template meta-programmers, when they refer to "buggy, costly and
error-prone O(N^N) recursive template instantiations" they all refer to
the final effect: each instantiation has a very concrete cost in time
and memory resources. whether the compiler is AST based or not. For the
record, there are compilers who vary in that memory cost in 2KiB - 10KiB
depending on complexity of the template parameter list - and that is
just to begin with.

You are also aware that the C++ standard itself has no properly defined
notion of "compile-time" for the purposes of meta-programming, including
the C++11 one; you'd have to deal in terms of translation units. Yet,
whenever template meta-programmers (which are a _/*blight*/_ according
to certain "acclaimed" people) refer to recursive instantiations and
"big-O" notation cost for them, they use the term "compile-time
evaluation". The standard also does not have terms like "catamorphism",
"anamorphism", "structure-preserving transformation", "monad", "monoid",
"profunctor" etc, but these have precise meaning when thinking
algorithmically for some decades now and are used in several useful C++
libraries and discussions about them.

However, your use of "metadata" and "metaprocessing", though a
neologistic conceptual portmanteau I understand the context of use, is
inapplicable. Meta-programming and lazy/eager evaluation during
instantiation are terms meta-programmers do use and do understand. So if
you are willing to go the terminology way, be prepared to be called upon
every little detail for clarification instead of provocatively replying
with libelous insults and misdirection. Especially since you come up
with very wild claims about what is and what is not "taxonomy". I do not
wish to be pedantic, but be certain that I am fully equipped to be,
intimidatingly so. There is nothing to gain by doing it though. Not a
single thing.

I am pretty certain that you are very much aware of what all this means.
As for std::tuple instantiations, I will again remind you what Louis
Dionne said about instantiation cost and urge you to study his
benchmarks quite well; they are pretty thorough.

> Anyway, let's focus on clarity and convenience and let implementers
> worry about compile times.
>
I do not believe that compiler implementers /are/ always right unless
they /prove/ themselves to be right; some of them seem to not be fully
aware of the internals of their /own/ compiler in relation to specific
behaviors and implementation details - and that comes from first hand
experience I had with certain people.

In relation to C++ annotated template parameter packs, I suggest that
you read /some part at least/ of the incomplete older drafts, which
despite incomplete and in rearrangement, did offer to people like Sean
and others who have been emailing me, ample evidence as to what they
actually are about.

Annotated template parameter packs are not about simply giving
index/range access, size constraints and pattern reflection for a pack
or generating packs out of other packs; they are about helping you
reduce code boilerplate that makes you go into pointless recursive
instantiations for trivial things, minimizing multiple function template
overloads and class template partial specializations.

They are about simple (and really advanced) generative programming more
than generic programming, despite some of their aspects due to their
embedded SFINAE character (which is intrinsic to template parameter
deducibility) can be used to do some sort of constraints. In that
respect, you will find quite interesting what I have to say about
interactions with concepts, when that section will be in.

In short, I remind you that just because I do not publicly contribute to
a well known C++ compiler or have a corporate lobby supporting me in the
EWG, one cannot automatically discredit any original contribution I am
trying to make on the basis of a personal agenda or will to appeal to
"the powers that be".

 From what I understand, the C++ standard community pretty much works in
two different worlds: the closed mailing lists where decisions are taken
about who is going to do what and when (regardless of the work people
are actually doing outside) and the politically correct but ill-purposed
"outside", some "recruiters" deal with, where at times everything is
completely staged up given that it is more about marketing than
substance. I would like to be proven wrong on this intuition, but it is
unfortunately based on my first-hand personal experience.

You have to understand that I am not trying to convince anybody of any
claim with ATPP; I think that they provably build upon certain
necessities that the community does have (see EWG#30) and indicate a
possible and viable evolutionary path. If you, or anybody else, is
willing to understand that technical discussions cannot be won by social
subterfuge and baseless ridicule for the sake of serving personal
agendas, then all is well. But any ad-hominem, will be returned to
sender accordingly, with evidence, regardless of who he is.

Regards,

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/.

--------------050305040907040602060304
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 09/20/2014 08:43 PM, David Krauss
      wrote:<br>
    </div>
    <blockquote
      cite="mid:FB215387-D0AC-4983-9ADD-C9FCD965D466@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <div>
        <div>On 2014&ndash;09&ndash;20, at 11:03 PM, Douglas Boffey &lt;<a
            moz-do-not-send="true"
            href="mailto:douglas.boffey@gmail.com">douglas.boffey@gmail.com</a>&gt;
          wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div dir="ltr">George &amp; David, are we here to try and
            improve C++ or to criticise each other?<br>
          </div>
        </blockquote>
        <br>
      </div>
      <div>If we&rsquo;re going to work together to improve C++, we all have
        to agree on terminology. &ldquo;Instantiation&rdquo; has a particular
        definition, and George&rsquo;s claim that <font face="Courier">std::tuple&lt;void,
          int()&gt;</font>&nbsp;carries instantiation cost doesn&rsquo;t fit it,
        because that specialization cannot be instantiated.</div>
      <div><br>
      </div>
      <br>
    </blockquote>
    <br>
    Regarding function and class template instantiation, one has to
    understand that the standard provides no description of the internal
    mechanics of instantiation representation, which is left to the
    mercy of the quality of people involved in a particular
    implementation. This is why template meta-programmers, when they
    refer to "buggy, costly and error-prone O(N^N) recursive template
    instantiations" they all refer to the final effect: each
    instantiation has a very concrete cost in time and memory resources.
    whether the compiler is AST based or not. For the record, there are
    compilers who vary in that memory cost in 2KiB - 10KiB depending on
    complexity of the template parameter list - and that is just to
    begin with.<br>
    <br>
    You are also aware that the C++ standard itself has no properly
    defined notion of "compile-time" for the purposes of
    meta-programming, including the C++11 one; you'd have to deal in
    terms of translation units. Yet, whenever template meta-programmers
    (which are a <u><i><b>blight</b></i></u> according to certain
    "acclaimed" people) refer to recursive instantiations and "big-O"
    notation cost for them, they use the term "compile-time evaluation".
    The standard also does not have terms like "catamorphism",
    "anamorphism", "structure-preserving transformation", "monad",
    "monoid", "profunctor" etc, but these have precise meaning when
    thinking algorithmically for some decades now and are used in
    several useful C++ libraries and discussions about them.<br>
    <br>
    However, your use of "metadata" and "metaprocessing", though a
    neologistic conceptual portmanteau I understand the context of use,
    is inapplicable. Meta-programming and lazy/eager evaluation during
    instantiation are terms meta-programmers do use and do understand.
    So if you are willing to go the terminology way, be prepared to be
    called upon every little detail for clarification instead of
    provocatively replying with libelous insults and misdirection.
    Especially since you come up with very wild claims about what is and
    what is not "taxonomy". I do not wish to be pedantic, but be certain
    that I am fully equipped to be, intimidatingly so. There is nothing
    to gain by doing it though. Not a single thing.<br>
    <br>
    I am pretty certain that you are very much aware of what all this
    means. As for std::tuple instantiations, I will again remind you
    what Louis Dionne said about instantiation cost and urge you to
    study his benchmarks quite well; they are pretty thorough.<br>
    <br>
    <blockquote
      cite="mid:FB215387-D0AC-4983-9ADD-C9FCD965D466@gmail.com"
      type="cite">
      <div>Anyway, let&rsquo;s focus on clarity and convenience and let
        implementers worry about compile times.</div>
      <div><br>
      </div>
    </blockquote>
    I do not believe that compiler implementers <i>are</i> always right
    unless they <i>prove</i> themselves to be right; some of them seem
    to not be fully aware of the internals of their <i>own</i> compiler
    in relation to specific behaviors and implementation details - and
    that comes from first hand experience I had with certain people.<br>
    <br>
    In relation to C++ annotated template parameter packs, I suggest
    that you read <i>some part at least</i> of the incomplete older
    drafts, which despite incomplete and in rearrangement, did offer to
    people like Sean and others who have been emailing me, ample
    evidence as to what they actually are about.<br>
    <br>
    Annotated template parameter packs are not about simply giving
    index/range access, size constraints and pattern reflection for a
    pack or generating packs out of other packs; they are about helping
    you reduce code boilerplate that makes you go into pointless
    recursive instantiations for trivial things, minimizing multiple
    function template overloads and class template partial
    specializations.<br>
    <br>
    They are about simple (and really advanced) generative programming
    more than generic programming, despite some of their aspects due to
    their embedded SFINAE character (which is intrinsic to template
    parameter deducibility) can be used to do some sort of constraints.
    In that respect, you will find quite interesting what I have to say
    about interactions with concepts, when that section will be in.<br>
    <br>
    In short, I remind you that just because I do not publicly
    contribute to a well known C++ compiler or have a corporate lobby
    supporting me in the EWG, one cannot automatically discredit any
    original contribution I am trying to make on the basis of a personal
    agenda or will to appeal to "the powers that be".<br>
    <br>
    From what I understand, the C++ standard community pretty much works
    in two different worlds: the closed mailing lists where decisions
    are taken about who is going to do what and when (regardless of the
    work people are actually doing outside) and the politically correct
    but ill-purposed "outside", some "recruiters" deal with, where at
    times everything is completely staged up given that it is more about
    marketing than substance. I would like to be proven wrong on this
    intuition, but it is unfortunately based on my first-hand personal
    experience.<br>
    <br>
    You have to understand that I am not trying to convince anybody of
    any claim with ATPP; I think that they provably build upon certain
    necessities that the community does have (see EWG#30) and indicate a
    possible and viable evolutionary path. If you, or anybody else, is
    willing to understand that technical discussions cannot be won by
    social subterfuge and baseless ridicule for the sake of serving
    personal agendas, then all is well. But any ad-hominem, will be
    returned to sender accordingly, with evidence, regardless of who he
    is.<br>
    <br>
    Regards,<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&quot; 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 />

--------------050305040907040602060304--

.

On 09/20/2014 06:03 PM, Douglas Boffey wrote:
> George & David, are we here to try and improve C++ or to criticise
> each other?
> --
>
I came here because I want to make a pretty small technical contribution
to a programming language I enjoy using, given that it has a public,
open forum for such a case. I am not trying to convince of a claim over
anything, but prove a possible evolutionary path in relation to
parameter packs. Other than that, to each his own.

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/.

.

This is a multi-part message in MIME format.
--------------070004070007040906090608
Content-Type: text/plain; charset=UTF-8; format=flowed


On 09/17/2014 09:41 PM, Sean Middleditch wrote:
> I think there's just a miscommunication here, maybe? George may not be
> using "instantiation" in the most precise technical definition from
> the standard but rather just referring to the work the compiler does
> when expanding the template in its internal type
> representation/AST/whatever (which while much less work than
> instantiation is still not zero work).
>
It seems to me that David started with "compiler doing zero work" in his
initial reply. In that context, yes, I am referring to the internal
representation that becomes exceedingly costly for many, many compiler
implementations. Some implementations vary in this between 2KiB - 5KiB
per "instantiation" and are a source for compile time shooting up. The
compiler is /never/ doing zero work, nor are the resource requirements
for such instantiations linear; the more numerous the parameters of the
pack you are working on individually, the more likely you are to observe
deviations from this character - or even internal compiler errors.

I think that it is _/very important/_ that C++11/C++14 pack expansion
triple-dot semantics already allow for structure-preserving
transformations when it comes to using template-type parameters as
"functions" for doing this.In essence, that "structure-preserving"
character of parameter packs is one of the attributes of the haskellian
/Functor/ (not to confuse with the C++ "functor" lingo of course).

But all the goodness in parameter pack transformation through the
triple-dot expansion rule has to happen wholesale to the entire pack in
which we cannot modify any internals without resorting to serious
boilerplate. That is what Abrahams is referring to in EWG#30 as trivial
operations. However, if you start touching these semantics, you pretty
soon find out that you are playing with fire with the template parameter
list mediated "pattern matching", in function template overloads and
class template partial specializations. That is an actual issue for
which the work on annotated template parameter packs tries to resolve.
This is why it considers sfinae and a pattern fundamentals.

Take note that as I said elsewhere, compile-time performance is a
/partial/ argument for extending pack semantics; the better motivation
is found when we think of how much boilerplate code we are getting rid
of for doing trivial things like accessing the internals of a pack
seamlessly. It seems to me that a lot of libraries that we use end up
re-implementing such facility. The fact that std::tuple implementations
can be shorter should be considered a benefit, I think.

Regards,

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/.

--------------070004070007040906090608
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 09/17/2014 09:41 PM, Sean
      Middleditch wrote:<br>
    </div>
    <blockquote
cite="mid:CALQmNFiC1EVr4wCa3EX=EBLYVqJHGH3SHi5dOqrPkPxppyRjcQ@mail.gmail.com"
      type="cite">
      <pre wrap="">I think there's just a miscommunication here, maybe? George may not be
using "instantiation" in the most precise technical definition from
the standard but rather just referring to the work the compiler does
when expanding the template in its internal type
representation/AST/whatever (which while much less work than
instantiation is still not zero work).

</pre>
    </blockquote>
    It seems to me that David started with "compiler doing zero work" in
    his initial reply. In that context, yes, I am referring to the
    internal representation that becomes exceedingly costly for many,
    many compiler implementations. Some implementations vary in this
    between 2KiB - 5KiB per "instantiation" and are a source for compile
    time shooting up. The compiler is <i>never</i> doing zero work, nor
    are the resource requirements for such instantiations linear; the
    more numerous the parameters of the pack you are working on
    individually, the more likely you are to observe deviations from
    this character - or even internal compiler errors.<br>
    <br>
    I think that it is <u><i>very important</i></u> that C++11/C++14
    pack expansion triple-dot semantics already allow for
    structure-preserving transformations when it comes to using
    template-type parameters as "functions" for doing this.In essence,
    that "structure-preserving" character of parameter packs is one of
    the attributes of the haskellian <i>Functor</i> (not to confuse
    with the C++ "functor" lingo of course).<br>
    <br>
    But all the goodness in parameter pack transformation through the
    triple-dot expansion rule has to happen wholesale to the entire pack
    in which we cannot modify any internals without resorting to serious
    boilerplate. That is what Abrahams is referring to in EWG#30 as
    trivial operations. However, if you start touching these semantics,
    you pretty soon find out that you are playing with fire with the
    template parameter list mediated "pattern matching", in function
    template overloads and class template partial specializations. That
    is an actual issue for which the work on annotated template
    parameter packs tries to resolve. This is why it considers sfinae
    and a pattern fundamentals.<br>
    <br>
    Take note that as I said elsewhere, compile-time performance is a <i>partial</i>
    argument for extending pack semantics; the better motivation is
    found when we think of how much boilerplate code we are getting rid
    of for doing trivial things like accessing the internals of a pack
    seamlessly. It seems to me that a lot of libraries that we use end
    up re-implementing such facility. The fact that std::tuple
    implementations can be shorter should be considered a benefit, I
    think.<br>
    <br>
    Regards,<br>
    <br>
    George<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&quot; 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 />

--------------070004070007040906090608--

.

--Apple-Mail=_F4E95454-6F83-4C6E-B636-25DAFD0F6CC0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-21, at 4:05 AM, George Makrydakis <irrequietus@gmail.com> wrote:

> Regarding function and class template instantiation, one has to understan=
d that the standard provides no description of the internal mechanics of in=
stantiation representation, which is left to the mercy of the quality of pe=
ople involved in a particular implementation. This is why template meta-pro=
grammers, when they refer to "buggy, costly and error-prone O(N^N) recursiv=
e template instantiations" they all refer to the final effect: each instant=
iation has a very concrete cost in time and memory resources. whether the c=
ompiler is AST based or not. For the record, there are compilers who vary i=
n that memory cost in 2KiB - 10KiB depending on complexity of the template =
parameter list - and that is just to begin with.

The implementations are what they are. Certainly, a template-id doesn't nee=
d to take so much space. I'd be surprised if mentioning std::tuple<void> gr=
abbed 2 KiB in the latest Clang or GCC. Remember that we're comparing the o=
verhead of representing the template-id std::tuple<void> to just the argume=
nt list <void>.

Moreover, you haven't provided any alternative. While you've been spending =
so much energy insisting that there are unacceptable costs in std::tuple, a=
nd that ATPP hasn't gotten its deserved credit, you've not mentioned by wha=
t means an ATPP implementation becomes more efficient. In particular, your =
implementation recommendation in =A74.1/61 (of your latest online draft) su=
ggests that ATPP metafunctions use an empty "holder for a pack" class templ=
ate typevector, which might as well be std::tuple.

The recommendation for "quickly altering the type parameter present at a gi=
ven position in the type vector" simply builds a new list  typevector<T...{=
N-1},X,R...>. This is no different to the splicing operations we have, and =
it still might as well be tuple. Further, T... and R... are new packs which=
 need to be separately represented by the compiler at potentially significa=
nt cost.

We can already implement alter_at more efficiently:

template< std::size_t n, typename X, typename ... T >
using alter_at =3D typename alter_at_impl<
    X, std::tuple< T ... >,
    std::make_index_sequence< n - 1 >,
    std::make_index_sequence< sizeof ... (T) - n >
>::type;

template< typename X, typename T, typename pre_seq, typename post_seq >
struct alter_at_impl;

template< typename X, typename T, std::size_t ... pre_seq, std::size_t ... =
post_seq >
struct alter_at_impl<
    X, T,
    std::index_sequence< pre_seq ... >,
    std::index_sequence< post_seq ... >
> {
    typedef std::tuple<
        std::tuple_element_t< pre_seq, T > ...,
        X,
        std::tuple_element_t< sizeof ... (pre_seq) + 1 + post_seq, T > ...
    > type;
};

A reasonable implementation may evaluate this as follows:
1. Construct the std::tuple< T ... > template-id by binding the pack direct=
ly to the template-name without a copy.=20
2. Evaluate the make_index_sequence aliases. The results are memoized for s=
mall values, or it can be an intrinsic for better performance. Bind the pre=
_seq and post_seq packs to the packs in the argument lists of the respectiv=
e index_sequences, no copy required.
3. Construct the result tuple by repeated indexing into the std::tuple< T .=
... >. The only overhead here is in instantiating tuple_element_t, which may=
 be implemented as it is in Clang, or it can be an intrinsic for better per=
formance. As an intrinsic, memoization may be bypassed, which would elimina=
te nearly all the memory overhead of alter_at.

Perhaps no current implementation has an intrinsic std::tuple_element for o=
ptimal efficiency. But, as the rest of us were discussing before, this does=
n't seem to be the current bottleneck in the system. In the long run though=
, it's pretty much inevitable.

> You are also aware that the C++ standard itself has no properly defined n=
otion of "compile-time" for the purposes of meta-programming, including the=
 C++11 one; you'd have to deal in terms of translation units.

Yes it does, it's called translation phase 8.

> Yet, whenever template meta-programmers (which are a blight according to =
certain "acclaimed" people)

Ad-hominem much? Also, takes one to know one.

> refer to recursive instantiations and "big-O" notation cost for them, the=
y use the term "compile-time evaluation".

Yes, we can make benchmarks and observe compiler performance. Seems to be a=
 real thing.

> The standard also does not have terms like "catamorphism", "anamorphism",=
 "structure-preserving transformation", "monad", "monoid", "profunctor" etc=
, but these have precise meaning when thinking algorithmically for some dec=
ades now and are used in several useful C++ libraries and discussions about=
 them.

You seem to mention these terms often, but without reference to anything. T=
here seems to be an insinuation that your metafunctions are more pure than =
other programmers', but to be solving the same problems, you have to be add=
ressing the same set of functions.

> However, your use of "metadata" and "metaprocessing", though a neologisti=
c conceptual portmanteau I understand the context of use, is inapplicable. =
Meta-programming and lazy/eager evaluation during instantiation are terms m=
eta-programmers do use and do understand. So if you are willing to go the t=
erminology way, be prepared to be called upon every little detail for clari=
fication instead of provocatively replying with libelous insults and misdir=
ection.

Well, metaprocessing is application of algorithms to create a program which=
 is structurally different from the source code. Metafunctions are the desc=
riptions of those algorithms and metadata comprises the domain of the funct=
ions.

Need more clarification? Ask for it.

> Especially since you come up with very wild claims about what is and what=
 is not "taxonomy".

The first time you mentioned catamorphism, anamorphism, etc., I used the wo=
rd "taxonomy" in asking what relevance those classifications had to the dis=
cussion at hand. The intent was not to be dismissive, but because the terms=
 do seem to be irrelevant, perhaps I happened to effectively (albeit accide=
ntally) dismiss your argument.

Harping endlessly on a single word I mentioned once, to make it sound like =
an epithet, makes you seem a bit manic.

> I do not wish to be pedantic, but be certain that I am fully equipped to =
be, intimidatingly so.

Well, please use C++ terminology correctly.

> They are about simple (and really advanced) generative programming more t=
han generic programming, despite some of their aspects due to their embedde=
d SFINAE character (which is intrinsic to template parameter deducibility) =
can be used to do some sort of constraints. In that respect, you will find =
quite interesting what I have to say about interactions with concepts, when=
 that section will be in.

Maybe I'll read it, maybe I won't. Chances are higher if you concretely sta=
te what advantages your notation gains over the closest equivalent algorith=
ms described in the existing notation.

Presuming that everyone naively uses recursion every time will gain no trac=
tion among those of us who don't.

> In short, I remind you that just because I do not publicly contribute to =
a well known C++ compiler

Do you privately contribute to an obscure compiler?

> or have a corporate lobby supporting me in the EWG, one cannot automatica=
lly discredit any original contribution I am trying to make on the basis of=
 a personal agenda or will to appeal to "the powers that be".

Not sure I follow, but we're all free to simply not like it.

> You have to understand that I am not trying to convince anybody of any cl=
aim with ATPP;

That's the problem. With no claims, there's no motivation and no context to=
 see how you can describe or process anamorphisms etc. better than a librar=
y-only alternative. A reader can sort-of extrapolate from examples to falsi=
fiable claims, but then you can always just say that the wrong claim was ex=
trapolated. It defeats the review process, and fundamentally obscures the p=
roposal.

> But any ad-hominem, will be returned to sender accordingly, with evidence=
, regardless of who he is.

Fabulous.

--=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=_F4E95454-6F83-4C6E-B636-25DAFD0F6CC0
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"><meta http-equiv=3D"Content-Type" content=3D"text/=
html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Dwindows-1252"></head><body style=3D"word-wrap: brea=
k-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><=
br><div><div>On 2014&ndash;09&ndash;21, at 4:05 AM, George Makrydakis &lt;<=
a href=3D"mailto:irrequietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote=
:</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Conte=
nt-Type">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">Regarding function and class te=
mplate instantiation, one has to
    understand that the standard provides no description of the internal
    mechanics of instantiation representation, which is left to the
    mercy of the quality of people involved in a particular
    implementation. This is why template meta-programmers, when they
    refer to "buggy, costly and error-prone O(N^N) recursive template
    instantiations" they all refer to the final effect: each
    instantiation has a very concrete cost in time and memory resources.
    whether the compiler is AST based or not. For the record, there are
    compilers who vary in that memory cost in 2KiB - 10KiB depending on
    complexity of the template parameter list - and that is just to
    begin with.<br></div></blockquote><div><br></div><div>The implementatio=
ns are what they are. Certainly, a template-id doesn&rsquo;t need to take s=
o much space. I&rsquo;d be surprised if mentioning <font face=3D"Courier">s=
td::tuple&lt;void&gt;</font> grabbed 2 KiB in the latest Clang or GCC. Reme=
mber that we&rsquo;re comparing the overhead of representing the template-i=
d&nbsp;<font face=3D"Courier">std::tuple&lt;void&gt;</font> to just the&nbs=
p;argument list&nbsp;<font face=3D"Courier">&lt;void&gt;</font>.</div><div>=
<br></div><div>Moreover, you haven&rsquo;t provided any alternative. While =
you&rsquo;ve been spending so much energy insisting that there are unaccept=
able costs in&nbsp;<font face=3D"Courier">std::tuple</font>, and that ATPP =
hasn&rsquo;t gotten its deserved credit, you&rsquo;ve not mentioned by what=
 means an ATPP implementation becomes more efficient. In particular, your i=
mplementation recommendation in =A74.1/61 (of your latest online draft) sug=
gests that ATPP metafunctions use an empty &ldquo;holder for a pack&rdquo; =
class template <font face=3D"Courier">typevector</font>, which might as wel=
l be <font face=3D"Courier">std::tuple</font>.</div><div><br></div><div>The=
 recommendation for "quickly altering the type&nbsp;parameter present at a =
given position in the&nbsp;type vector&rdquo; simply builds a new list&nbsp=
;<span class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span><span s=
tyle=3D"font-family: Courier;">typevector</span><font face=3D"Courier">&lt;=
T...{N-1},X,R...&gt;</font>. This is no different to the splicing operation=
s we have, and it still might as well be <font face=3D"Courier">tuple</font=
>. Further,&nbsp;<font face=3D"Courier">T...</font> and <font face=3D"Couri=
er">R...</font> are new packs which need to be separately represented by th=
e compiler at potentially significant cost.</div><div><br></div><div>We can=
 already implement <font face=3D"Courier">alter_at</font> more efficiently:=
</div><div><br></div><div><font face=3D"Courier">template&lt; std::size_t n=
, typename X, typename ... T &gt;</font></div><div><font face=3D"Courier">u=
sing alter_at =3D typename alter_at_impl&lt;</font></div><div><font face=3D=
"Courier">&nbsp; &nbsp; X, std::tuple&lt; T ... &gt;,</font></div><div><fon=
t face=3D"Courier">&nbsp; &nbsp; std::make_index_sequence&lt; n - 1 &gt;,</=
font></div><div><font face=3D"Courier">&nbsp; &nbsp; std::make_index_sequen=
ce&lt; sizeof ... (T) - n &gt;</font></div><div><font face=3D"Courier">&gt;=
::type;</font></div><div><font face=3D"Courier"><br></font></div><div><font=
 face=3D"Courier">template&lt;&nbsp;</font><span style=3D"font-family: Cour=
ier;">typename X, typename T,</span>&nbsp;<span style=3D"font-family: Couri=
er;">typename pre_seq, typename post_seq &gt;</span></div><div><font face=
=3D"Courier">struct alter_at_impl;</font></div><div><font face=3D"Courier">=
<br></font></div><div><font face=3D"Courier">template&lt;&nbsp;</font><span=
 style=3D"font-family: Courier;">typename X, typename T,&nbsp;</span><span =
style=3D"font-family: Courier;">std::size_t ... pre_seq, std::size_t ... po=
st_seq &gt;</span></div><div><font face=3D"Courier">struct alter_at_impl&lt=
;</font></div><div><font face=3D"Courier">&nbsp; &nbsp; X, T,</font></div><=
div><font face=3D"Courier">&nbsp; &nbsp; std::index_sequence&lt; pre_seq ..=
.. &gt;,</font></div><div><font face=3D"Courier">&nbsp; &nbsp; std::index_se=
quence&lt; post_seq ... &gt;</font></div><div><font face=3D"Courier">&gt; {=
</font></div><div><font face=3D"Courier">&nbsp; &nbsp; typedef std::tuple&l=
t;</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; std:=
:tuple_element_t&lt; pre_seq, T &gt; ...,</font></div><div><font face=3D"Co=
urier">&nbsp; &nbsp; &nbsp; &nbsp; X,</font></div><div><font face=3D"Courie=
r">&nbsp; &nbsp; &nbsp; &nbsp; std::tuple_element_t&lt; sizeof ... (pre_seq=
) + 1 + post_seq, T &gt; ...</font></div><div><font face=3D"Courier">&nbsp;=
 &nbsp; &gt; type;</font></div><div><font face=3D"Courier">};</font></div><=
div><br></div><div>A reasonable implementation may evaluate this as follows=
:</div><div>1. Construct the <font face=3D"Courier">std::tuple&lt; T ... &g=
t;</font>&nbsp;template-id by binding the pack directly to the template-nam=
e without a copy.&nbsp;</div><div>2. Evaluate the <font face=3D"Courier">ma=
ke_index_sequence</font> aliases. The results are memoized for small values=
, or it can be an intrinsic for better performance. Bind the <font face=3D"=
Courier">pre_seq</font> and <font face=3D"Courier">post_seq</font> packs to=
 the packs in the argument lists of the respective <font face=3D"Courier">i=
ndex_sequence</font>s, no copy required.</div><div>3. Construct the result =
tuple by repeated indexing into the&nbsp;<span style=3D"font-family: Courie=
r;">std::tuple&lt; T ... &gt;</span>. The only overhead here is in instanti=
ating <font face=3D"Courier">tuple_element_t</font>, which may be implement=
ed as it is in Clang, or it can be an intrinsic for better performance. As =
an intrinsic, memoization may be bypassed, which would eliminate nearly all=
 the memory overhead of <font face=3D"Courier">alter_at</font>.</div><div><=
br></div><div>Perhaps no current implementation has an intrinsic <font face=
=3D"Courier">std::tuple_element</font> for optimal efficiency. But, as the =
rest of us were discussing before, this doesn&rsquo;t seem to be the curren=
t bottleneck in the system. In the long run though, it&rsquo;s pretty much =
inevitable.</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcolo=
r=3D"#FFFFFF">
   =20
    You are also aware that the C++ standard itself has no properly
    defined notion of "compile-time" for the purposes of
    meta-programming, including the C++11 one; you'd have to deal in
    terms of translation units.</div></blockquote><div><br></div><div>Yes i=
t does, it&rsquo;s called translation phase 8.</div><br><blockquote type=3D=
"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF"> Yet, whenever template me=
ta-programmers
    (which are a <u><i><b>blight</b></i></u> according to certain
    "acclaimed" people) </div></blockquote><div><br></div><div>Ad-hominem m=
uch? Also, takes one to know one.</div><br><blockquote type=3D"cite"><div t=
ext=3D"#000000" bgcolor=3D"#FFFFFF">refer to recursive instantiations and "=
big-O"
    notation cost for them, they use the term "compile-time evaluation&rdqu=
o;.</div></blockquote><div><br></div><div>Yes, we can make benchmarks and o=
bserve compiler performance. Seems to be a real thing.</div><br><blockquote=
 type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">The standard also =
does not have terms like "catamorphism",
    "anamorphism", "structure-preserving transformation", "monad",
    "monoid", "profunctor" etc, but these have precise meaning when
    thinking algorithmically for some decades now and are used in
    several useful C++ libraries and discussions about them.<br></div></blo=
ckquote><div><br></div><div>You seem to mention these terms often, but with=
out reference to anything. There seems to be an insinuation that your metaf=
unctions are more pure than other programmers&rsquo;, but to be solving the=
 same problems, you have to be addressing the same set of functions.</div><=
br><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">
   =20
    However, your use of "metadata" and "metaprocessing", though a
    neologistic conceptual portmanteau I understand the context of use,
    is inapplicable. Meta-programming and lazy/eager evaluation during
    instantiation are terms meta-programmers do use and do understand.
    So if you are willing to go the terminology way, be prepared to be
    called upon every little detail for clarification instead of
    provocatively replying with libelous insults and misdirection.</div></b=
lockquote><div><br></div><div>Well, metaprocessing is application of algori=
thms to create a program which is structurally different from the source co=
de. Metafunctions are the descriptions of those algorithms and metadata com=
prises the domain of the functions.</div><div><br></div><div>Need more clar=
ification? Ask for it.</div><br><blockquote type=3D"cite"><div text=3D"#000=
000" bgcolor=3D"#FFFFFF">Especially since you come up with very wild claims=
 about what is and
    what is not "taxonomy&rdquo;. </div></blockquote><div><br></div><div>Th=
e first time you mentioned catamorphism, anamorphism, etc., I used the word=
 &ldquo;taxonomy&rdquo; in asking what relevance those classifications had =
to the discussion at hand. The intent was not to be dismissive, but because=
 the terms do seem to be irrelevant, perhaps I happened to effectively (alb=
eit accidentally) dismiss your argument.</div><div><br></div><div>Harping e=
ndlessly on a single word I mentioned once, to make it sound like an epithe=
t, makes you seem a bit manic.</div><br><blockquote type=3D"cite"><div text=
=3D"#000000" bgcolor=3D"#FFFFFF">I do not wish to be pedantic, but be certa=
in
    that I am fully equipped to be, intimidatingly so. </div></blockquote><=
div><br></div><div>Well, please use C++ terminology correctly.</div><div><b=
r></div><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF"=
>They are about simple (and really advanced) generative programming
    more than generic programming, despite some of their aspects due to
    their embedded SFINAE character (which is intrinsic to template
    parameter deducibility) can be used to do some sort of constraints.
    In that respect, you will find quite interesting what I have to say
    about interactions with concepts, when that section will be in.<br></di=
v></blockquote><div><br></div><div>Maybe I&rsquo;ll read it, maybe I won&rs=
quo;t. Chances are higher if you concretely state what advantages your nota=
tion gains over the closest equivalent algorithms described in the existing=
 notation.</div><div><br></div><div>Presuming that everyone naively uses re=
cursion every time will gain no traction among those of us who don&rsquo;t.=
</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFF=
F">In short, I remind you that just because I do not publicly
    contribute to a well known C++ compiler </div></blockquote><div><br></d=
iv><div>Do you privately contribute to an obscure compiler?</div><br><block=
quote type=3D"cite"><div text=3D"#000000" bgcolor=3D"#FFFFFF">or have a cor=
porate lobby
    supporting me in the EWG, one cannot automatically discredit any
    original contribution I am trying to make on the basis of a personal
    agenda or will to appeal to "the powers that be&rdquo;.<br></div></bloc=
kquote><div><br></div><div>Not sure I follow, but we&rsquo;re all free to s=
imply not like it.</div><br><blockquote type=3D"cite"><div text=3D"#000000"=
 bgcolor=3D"#FFFFFF">You have to understand that I am not trying to convinc=
e anybody of
    any claim with ATPP; </div></blockquote><div><br></div><div>That&rsquo;=
s the problem. With no claims, there&rsquo;s no motivation and no context t=
o see how you can describe or process anamorphisms etc. better than a libra=
ry-only alternative. A reader can sort-of extrapolate from examples to fals=
ifiable claims, but then you can always just say that the wrong claim was e=
xtrapolated. It defeats the review process, and fundamentally obscures the =
proposal.</div><br><blockquote type=3D"cite"><div text=3D"#000000" bgcolor=
=3D"#FFFFFF">But any ad-hominem, will be
    returned to sender accordingly, with evidence, regardless of who he
    is.<br></div></blockquote><br></div><div>Fabulous.</div><br></body></ht=
ml>

<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 />

--Apple-Mail=_F4E95454-6F83-4C6E-B636-25DAFD0F6CC0--

.

--Apple-Mail=_16770954-CBCF-455A-AB00-5A33C72F371C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-18, at 3:23 AM, George Makrydakis <irrequietus@gmail.com> wrote:

> It seems to me that David started with "compiler doing zero work" in his =
initial reply. In that context, yes, I am referring to the internal represe=
ntation that becomes exceedingly costly for many, many compiler implementat=
ions. Some implementations vary in this between 2KiB - 5KiB per "instantiat=
ion" and are a source for compile time shooting up. The compiler is never d=
oing zero work, nor are the resource requirements for such instantiations l=
inear; the more numerous the parameters of the pack you are working on indi=
vidually, the more likely you are to observe deviations from this character=
 - or even internal compiler errors.

Read carefully. The presumption is that you have a pack typename ... T in t=
he first place.

> Wrapping a pack as a tuple type, i.e. merely naming std::tuple< T ... >, =
is essentially zero work for the compiler.

The compiler may copy the bulk of the pack every time it's passed again, bu=
t that's just poor implementation. GCC's initial implementation preferred t=
o forbid passing a pack to a parameter list that did not include a pack, an=
d stayed that way for quite a while, because it prefers to treat packs as r=
eusable units in argument binding.

You never proposed an improvement to this situation, and it's not really up=
 to the language spec to dictate implementation memory efficiency. The best=
 C++ can do is enable an efficient solution, and that is already done.

Louis concern which I was replying to was that std::tuple is slower than e.=
g. your typevector because of the cost of its instantiation. In this contex=
t "instantiation" definitely means creating the definition of the class, no=
t only naming a specialization.

--=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=_16770954-CBCF-455A-AB00-5A33C72F371C
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;09&ndash;18, at 3:23 AM, George Makrydakis &lt;<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>&gt; wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><span style=3D"font-fam=
ily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
 background-color: rgb(255, 255, 255); float: none; display: inline !import=
ant;">It seems to me that David started with "compiler doing zero work" in =
his initial reply. In that context, yes, I am referring to the internal rep=
resentation that becomes exceedingly costly for many, many compiler impleme=
ntations. Some implementations vary in this between 2KiB - 5KiB per "instan=
tiation" and are a source for compile time shooting up. The compiler is<spa=
n class=3D"Apple-converted-space">&nbsp;</span></span><i style=3D"font-fami=
ly: Helvetica; font-size: 12px; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: auto; text-align: sta=
rt; text-indent: 0px; text-transform: none; white-space: normal; widows: au=
to; word-spacing: 0px; -webkit-text-stroke-width: 0px;">never</i><span styl=
e=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-vari=
ant: normal; font-weight: normal; letter-spacing: normal; line-height: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; background-color: rgb(255, 255, 255); float: none; display: i=
nline !important;"><span class=3D"Apple-converted-space">&nbsp;</span>doing=
 zero work, nor are the resource requirements for such instantiations linea=
r; the more numerous the parameters of the pack you are working on individu=
ally, the more likely you are to observe deviations from this character - o=
r even internal compiler errors.</span><br style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote>=
</div><br><div><div>Read carefully. The presumption is that you have a pack=
&nbsp;<font face=3D"Courier">typename ... T</font>&nbsp;in the first place.=
</div><div><br></div><div><blockquote type=3D"cite">Wrapping a pack as a tu=
ple type, i.e. merely naming&nbsp;<font face=3D"Courier">std::tuple&lt; T .=
... &gt;</font>, is essentially zero work for the compiler.</blockquote><br>=
</div></div><div>The compiler may copy the bulk of the pack every time it&r=
squo;s passed again, but that&rsquo;s just poor implementation. GCC&rsquo;s=
 initial implementation preferred to forbid passing a pack to a parameter l=
ist that did not include a pack, and stayed that way for quite a while, bec=
ause it prefers to treat packs as reusable units in argument binding.</div>=
<div><br></div><div>You never proposed an improvement to this situation, an=
d it&rsquo;s not really up to the language spec to dictate implementation m=
emory efficiency. The best C++ can do is enable an efficient solution, and =
that is already done.</div><div><br></div><div>Louis concern which I was re=
plying to was that <font face=3D"Courier">std::tuple</font> is slower than =
e.g. your&nbsp;<font face=3D"Courier">typevector</font>&nbsp;because of the=
 cost of its instantiation. In this context &ldquo;instantiation&rdquo; def=
initely means creating the definition of the class, not only naming a speci=
alization.</div><div><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&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 />

--Apple-Mail=_16770954-CBCF-455A-AB00-5A33C72F371C--

.