------=_Part_448_928059041.1416179202565
Content-Type: text/plain; charset=UTF-8

I noticed that the proposal about fold expressions [1] made it to the C++17
standard (unless later retracted) and decided to think a little bit about
what I find good and what I find perfectible in the proposal. While I like
the general idea and the syntax, there are still some things that bother me:

   - Why the restriction to some operators?


   - Why the restriction to even less operators for empty parameter packs?


Restriction to some operators

I don't know about the discussions in Urbana that lead to the acceptance of
the proposal but I find strange to limit it to some operators while it seems
that any binary function could work here. The only problem I see is with the
following form:

return (true + ... + args);

Considering that any binary operation is allowed, if the operation's name is
long, writing it twice will be redundant. Other than that, allowing any
binary
operations in fold expressions seem reasonable. Since a fold expression can
easily be translated to its "complete" form such as f(f(f(a, b), c), d),
the usual lookup rules can be applied without a problem (with ADL).

Empty parameter packs

There are IMO two problems with empty parameter packs in the fold
expressions
proposal:

   - The number of operators allowed is even smaller.


   - The returned result may be inconsistent.


Concerning the second point, if we are adding strings in a variadic
algorithm,
we might be really surprised to have our function always return a string,
then
return an integer (or try to construct a string from an integer) when we
feed
it an empty parameter pack.

The problem here is clear: whatever the types we want to work with, there
will
be a special case in our algorithms when we give them an empty parameter
pack
and they will try to do stuff with integers instead of with the types we
want
them to work with.

What we really want when giving an empty parameter pack is to get the
identity
element [2] which corresponds to the type-operation pair. The current
proposal
chooses to provide the identity elements of the most common operators for
the
most common types. That may be helpful in some cases, but that's not generic
enough and may lead to surprise.

The problem is that getting the identity element for a type-operation pair
requires to know about the type and the operation. While the operation is
always known in fold expressions, the type is especially unknown in the case
of an empty parameter pack, especially where we need it. That said, the
proposal for fixed size parameter packs [3] could fix half of the problem.
Consider the following algorithm using N4072:

template<std::size_t N>
int multiply(int...[N] values)
{
    return (values * ...);
}

In this case, the required type is known, even if the parameter pack is
empty.
The identity element for an integer multiplication is 1, so this algorithm
would
return 1 for an empty parameter pack. The following algorithm:

template<std::size_t N>
matrix<2, 2> multiply(matrix<2, 2>...[N] values)
{
    return (values * ...);
}

would return a matrix<2, 2>{ {1, 0}, {0, 1} } for an empty parameter pack,
which is the identity element for the matrix<2, 2> multiplication. However,
if these
two algorithms cohabit, then feeding multiply an empty parameter pack would
be
ambiguous, so even this solution does not properly work.

std::identity_element

What we really want is the following lines of code to work:

template<typename... Args>
auto multiply(Args... args)
{
    return (args * ...);
}

int i = multiply(2, 3, 4); // i == 24
int j = multiply(); // j == 1 (identity element for integer multiplication)
matrix<2, 2> mat = multiply(); // mat == matrix<2, 2>{ {1, 0}, {0, 1} };

A generic design would let the users define what the identity element is
for their
class. This could probably be done thanks to template specialization, for
example,
with this kind of variable template:

namespace std
{
    template<>
    matrix<2, 2> identity_element<matrix<2, 2>, std::multiplies> = {
        { 1, 0 },
        { 0, 1 }
    };
}

And then we could add a rule stating that a fold expression with an empty
parameter
pack returns a magic object which could roughly be implement as:

template<template<typename...> typename BinaryFunc>
struct magic_object
{
    template<typename T>
    operator T() const
    {
        return std::identity_element<T, BinaryFunc>;
    }
};

One problem however is that this solution only works with template
functors. It did
not manage to find a way to have this solution interact nicely with the
operators
and the other non-object functions.

Questions

What do you think of such a solution to make fold expressions even more
generic and
usable (and refinable)? Also, do you have a smart/elegant solution to solve
my last
problem with operators and non-object functions?

If these ideas seem interesting, I could even expand them to include binary
functions
that only have a a right identity element or a left identity element: in
function of the
direction of the fold, with and empty parameter pack, the compiler woud
first look for
the appropriate identity element (std::left_identity_element or
std::right_identity_element),
then, if none is found, look for the general std::identity_element. Anyway,
if no
valid specialization is found, the program is ill-formed.


[1]: http://isocpp.org/files/papers/n4295.html
[2]: https://en.wikipedia.org/wiki/Identity_element
[3]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4072.html

--

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

<div dir=3D"ltr">I noticed that the proposal about fold expressions [1] mad=
e it to the C++17<br>standard (unless later retracted) and decided to think=
 a little bit about<br>what I find good and what I find perfectible in the =
proposal. While I like<br>the general idea and the syntax, there are still =
some things that bother me:<br><ul><li>Why the restriction to some operator=
s?</li></ul><ul><li>Why the restriction to even less operators for empty pa=
rameter packs?</li></ul><br><font size=3D"4">Restriction to some operators<=
/font><br><br>I don't know about the discussions in Urbana that lead to the=
 acceptance of<br>the proposal but I find strange to limit it to some opera=
tors while it seems<br>that any binary function could work here. The only p=
roblem I see is with the<br>following form:<br><br><div style=3D"margin-lef=
t: 40px;"><span style=3D"font-family: courier new,monospace;">return (true =
+ ... + args);<br></span></div><br>Considering that any binary operation is=
 allowed, if the operation's name is<br>long, writing it twice will be redu=
ndant. Other than that, allowing any binary<br>operations in fold expressio=
ns seem reasonable. Since a fold expression can<br>easily be translated to =
its "complete" form such as<span style=3D"font-family: courier new,monospac=
e;"> f(f(f(a, b), c), d)</span>,<br>the usual lookup rules can be applied w=
ithout a problem (with ADL).<br><font size=3D"4"><br>Empty parameter packs<=
/font><br><br>There are IMO two problems with empty parameter packs in the =
fold expressions<br>proposal:<br><ul><li>The number of operators allowed is=
 even smaller.</li></ul><ul><li>The returned result may be inconsistent.</l=
i></ul><br>Concerning the second point, if we are adding strings in a varia=
dic algorithm,<br>we might be really surprised to have our function always =
return a string, then<br>return an integer (or try to construct a string fr=
om an integer) when we feed<br>it an empty parameter pack.<br><br>The probl=
em here is clear: whatever the types we want to work with, there will<br>be=
 a special case in our algorithms when we give them an empty parameter pack=
<br>and they will try to do stuff with integers instead of with the types w=
e want<br>them to work with.<br><br>What we really want when giving an empt=
y parameter pack is to get the identity<br>element [2] which corresponds to=
 the type-operation pair. The current proposal<br>chooses to provide the id=
entity elements of the most common operators for the<br>most common types. =
That may be helpful in some cases, but that's not generic<br>enough and may=
 lead to surprise.<br><br>The problem is that getting the identity element =
for a type-operation pair<br>requires to know about the type and the operat=
ion. While the operation is<br>always known in fold expressions, the type i=
s especially unknown in the case<br>of an empty parameter pack, especially =
where we need it. That said, the<br>proposal for fixed size parameter packs=
 [3] could fix half of the problem.<br>Consider the following algorithm usi=
ng N4072:<br><br><div style=3D"margin-left: 40px;"><span style=3D"font-fami=
ly: courier new,monospace;">template&lt;std::size_t N&gt;<br>int multiply(i=
nt...[N] values)<br>{<br>&nbsp;&nbsp;&nbsp; return (values * ...);<br>}<br>=
</span></div><br>In this case, the required type is known, even if the para=
meter pack is empty.<br>The identity element for an integer multiplication =
is 1, so this algorithm would<br>return 1 for an empty parameter pack. The =
following algorithm:<br><br><div style=3D"margin-left: 40px;"><span style=
=3D"font-family: courier new,monospace;">template&lt;std::size_t N&gt;<br>m=
atrix&lt;2, 2&gt; multiply(matrix&lt;2, 2&gt;...[N] values)<br>{<br>&nbsp;&=
nbsp;&nbsp; return (values * ...);<br>}<br></span></div><br>would return a =
<span style=3D"font-family: courier new,monospace;">matrix&lt;2, 2&gt;{ {1,=
 0}, {0, 1} } </span>for an empty parameter pack,<br>which is the identity =
element for the <span style=3D"font-family: courier new,monospace;">matrix&=
lt;2, 2&gt; </span>multiplication. However, if these<br>two algorithms coha=
bit, then feeding multiply an empty parameter pack would be<br>ambiguous, s=
o even this solution does not properly work.<br><br><span style=3D"font-fam=
ily: courier new,monospace;"><font size=3D"4">std::identity_element</font><=
/span><br><br>What we really want is the following lines of code to work:<b=
r><br><div style=3D"margin-left: 40px;"><span style=3D"font-family: courier=
 new,monospace;">template&lt;typename... Args&gt;<br>auto multiply(Args... =
args)<br>{<br>&nbsp;&nbsp;&nbsp; return (args * ...);<br>}<br><br>int i =3D=
 multiply(2, 3, 4); // i =3D=3D 24<br>int j =3D multiply(); // j =3D=3D 1 (=
identity element for integer multiplication)<br>matrix&lt;2, 2&gt; mat =3D =
multiply(); // mat =3D=3D matrix&lt;2, 2&gt;{ {1, 0}, {0, 1} };<br></span><=
/div><br>A generic design would let the users define what the identity elem=
ent is for their<br>class. This could probably be done thanks to template s=
pecialization, for example,<br>with this kind of variable template:<br><br>=
<div style=3D"margin-left: 40px;"><span style=3D"font-family: courier new,m=
onospace;">namespace std<br>{<br>&nbsp;&nbsp;&nbsp; template&lt;&gt;<br>&nb=
sp;&nbsp;&nbsp; matrix&lt;2, 2&gt; identity_element&lt;matrix&lt;2, 2&gt;, =
std::multiplies&gt; =3D {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { 1=
, 0 },<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { 0, 1 }<br>&nbsp;&nbs=
p;&nbsp; };<br>}<br></span></div><br>And then we could add a rule stating t=
hat a fold expression with an empty parameter<br>pack returns a magic objec=
t which could roughly be implement as:<br><br><div style=3D"margin-left: 40=
px;"><span style=3D"font-family: courier new,monospace;">template&lt;templa=
te&lt;typename...&gt; typename BinaryFunc&gt;<br>struct magic_object<br>{<b=
r>&nbsp;&nbsp;&nbsp; template&lt;typename T&gt;<br>&nbsp;&nbsp;&nbsp; opera=
tor T() const<br>&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; return std::identity_element&lt;T, BinaryFunc&gt;;<br>&nbsp;&nbsp;=
&nbsp; }<br>};<br></span></div><br>One problem however is that this solutio=
n only works with template functors. It did<br>not manage to find a way to =
have this solution interact nicely with the operators<br>and the other non-=
object functions.<br><br><font size=3D"4">Questions</font><br><br>What do y=
ou think of such a solution to make fold expressions even more generic and<=
br>usable (and refinable)? Also, do you have a smart/elegant solution to so=
lve my last<br>problem with operators and non-object functions?<br><br>If t=
hese ideas seem interesting, I could even expand them to include binary fun=
ctions<br>that only have a a right identity element or a left identity elem=
ent: in function of the<br>direction of the fold, with and empty parameter =
pack, the compiler woud first look for<br>the appropriate identity element =
(<span style=3D"font-family: courier new,monospace;">std::left_identity_ele=
ment </span>or <span style=3D"font-family: courier new,monospace;">std::rig=
ht_identity_element</span>),<br>then, if none is found, look for the genera=
l <span style=3D"font-family: courier new,monospace;">std::identity_element=
</span>. Anyway, if no<br>valid specialization is found, the program is ill=
-formed.<br><br><br>[1]: <a href=3D"http://isocpp.org/files/papers/n4295.ht=
ml">http://isocpp.org/files/papers/n4295.html</a><br>[2]: <a href=3D"https:=
//en.wikipedia.org/wiki/Identity_element">https://en.wikipedia.org/wiki/Ide=
ntity_element</a><br>[3]: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2014/n4072.html">http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2014/n4072.html</a><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_448_928059041.1416179202565--

.

On 11/17/2014 12:06 AM, Ed wrote:
> I noticed that the proposal about fold expressions [1] made it to the C++17
> standard (unless later retracted) and decided to think a little bit about
> what I find good and what I find perfectible in the proposal. While I like
> the general idea and the syntax, there are still some things that bother me:
>
>   * Why the restriction to some operators?
>
>   * Why the restriction to even less operators for empty parameter packs?
>
>
> Restriction to some operators
>
> I don't know about the discussions in Urbana that lead to the acceptance of
> the proposal but I find strange to limit it to some operators while it seems
> that any binary function could work here.

Regarding "some operators": Which ones are missing, in your opinion?

Regarding "any binary function": Yes, it's possible to make that work.
I believe the original author has no intent to make this more general,
so if you wish to go ahead, feel free to propose that.  I'd like to see
some investigation into the issue whether  (args f ...)   (where "f" is
the name of an arbitrary function) could be syntactically confused with
a part of a varargs function declaration.

> Empty parameter packs
>
> There are IMO two problems with empty parameter packs in the fold expressions
> proposal:
>
>   * The number of operators allowed is even smaller.
>
>   * The returned result may be inconsistent.
>
>
> Concerning the second point, if we are adding strings in a variadic algorithm,
> we might be really surprised to have our function always return a string, then
> return an integer (or try to construct a string from an integer) when we feed
> it an empty parameter pack.

Don't do that, then.

> The problem here is clear: whatever the types we want to work with, there will
> be a special case in our algorithms when we give them an empty parameter pack
> and they will try to do stuff with integers instead of with the types we want
> them to work with.

> namespace std
> {
>     template<>
>     matrix<2, 2> identity_element<matrix<2, 2>, std::multiplies> = {
>         { 1, 0 },
>         { 0, 1 }
>     };
> }

This is an awful lot of machinery, and adds more dependencies from the
core language to the standard library.  What's the problem we actually
need to solve? Is it so hard to write an additional overload for the
empty pack case?  Example:


my_type f()
{
  return my_type();  // or whatever the identity element is
}

template<class ... T>
my_type f(T... x)
{
  return (x my_fold_operation ...);
}


This also addresses the left_identity / right_identity issue.


> One problem however is that this solution only works with template functors. It did
> not manage to find a way to have this solution interact nicely with the operators
> and the other non-object functions.

What do you mean with "non-object" functions?
You already used std::multiplies in your syntax above, instead of "*",
what the user actually wrote in the fold expression.  How is that
mapping going to happen?

> Questions
>
> What do you think of such a solution to make fold expressions even more generic and
> usable (and refinable)? Also, do you have a smart/elegant solution to solve my last
> problem with operators and non-object functions?

So far, I'm not convinced the specification and implementation cost outweighs
the benefits.  The N4295 restrictions were carefully crafted to keep these costs
low.

Also, I'm wondering whether one of the other proposals that try to make
template parameter packs more accessible would help address this in any way.

Jens

--

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

Le lundi 17 novembre 2014 23:46:31 UTC+1, Jens Maurer a =C3=A9crit :=20
>
> Regarding "some operators": Which ones are missing, in your opinion?=20
>

That's a case of poor formulation: with "some operators", I meant that
operators are no more than "regular" binary functions with some sugar
added. It boils down to "some functions".
=20

> Regarding "any binary function": Yes, it's possible to make that work.=20
> I believe the original author has no intent to make this more general,=20
> so if you wish to go ahead, feel free to propose that.  I'd like to see=
=20
> some investigation into the issue whether  (args f ...)   (where "f" is=
=20
> the name of an arbitrary function) could be syntactically confused with=
=20
> a part of a varargs function declaration.=20
>

Well, I am investing things. Actually, me creating this topic was also to
make things clearer in my head by writing them down. Your question is
interesting though.=20

Don't do that, then.=20
>

I have no problem not doing it, but I have concerns about whether always
defaulting (args + ...) to an integer when the parameter pack is empty may
be the source of silent conversions and silent problems. Instead of giving
privileges to integers alone, I would almost prefere the program to be
ill-formed when an empty parameter pack is given to a fold expression
rather than having silent problems. Even for integers, the expression
(args + ...) can trivially be converted to (args + ... + 0) anyway. Not=20
having
the special cases for some operators can avoid silent and tricky problems.

This is an awful lot of machinery, and adds more dependencies from the=20
> core language to the standard library.  What's the problem we actually=20
> need to solve? Is it so hard to write an additional overload for the=20
> empty pack case?  Example:=20
>
>
> my_type f()=20
> {=20
>   return my_type();  // or whatever the identity element is=20
> }=20
>
> template<class ... T>=20
> my_type f(T... x)=20
> {=20
>   return (x my_fold_operation ...);=20
> }=20
>
> This also addresses the left_identity / right_identity issue.=20
>

I thought of two solutions to make "some built-in types" and "user-defined=
=20
types"
equal regarding the (args + ...) case. The first solution was to always=20
make the
program ill-formed as explained a little bit earlier in this post. The=20
second solution
was to come up with a generic solution that could work if sufficient=20
information is
given. And I have to agree, it resulted in an awful lot of machinery.

> One problem however is that this solution only works with template=20
> functors. It did=20
> > not manage to find a way to have this solution interact nicely with the=
=20
> operators=20
> > and the other non-object functions.=20
>
> What do you mean with "non-object" functions?=20
> You already used std::multiplies in your syntax above, instead of "*",=20
> what the user actually wrote in the fold expression.  How is that=20
> mapping going to happen?
>

That's the problem I had: it is possible to specialize a template for a=20
type or
for a template (this is why I used std::multiplies) but it is not possible=
=20
to
specialize a template for a "function name" such as operator*. The mapping=
=20
is
indeed a problem that could only be solved with compiler magic and that's=
=20
not
elegant.=20

So far, I'm not convinced the specification and implementation cost=20
> outweighs=20
> the benefits.  The N4295 restrictions were carefully crafted to keep thes=
e=20
> costs=20
> low.
>

I have to agree that the implementation costs are too high. But why I=20
understand
the restrictions of N4295, I still feel that the rules for empty parameter=
=20
packs are
too strict (only work with some types) and may introduce problems (silent=
=20
conversion
of a type from a integer. Fortunately, standard types generally have=20
explicit constructors
when they take only one parameter but not all libraries do that properly.=
=20
Imagine a
sum function that only returns (args + ...). If you give it some array type=
=20
with a
non-explicit size_type constructor and and operator+ for concatenation,=20
you're up
for some surprises. The standard types don't have these pitfalls, but there=
=20
are obviously
some libraries around that do. My point is that this is not very type-safe.=
=20
The type-safe
solutions I thought of were either removing the special cases for empty=20
parameters or
creating a generic type-safe solutions, but it proved too hard/unpractical.

Also, I'm wondering whether one of the other proposals that try to make=20
> template parameter packs more accessible would help address this in any=
=20
> way.=20
>
> Jens
>
=20
I also hope that some other template parameter pack proposal will offer=20
other solutions :)
Meanwhile, I am developping a small library with fold funtions to check=20
what I can
ultimetely do with regards to empty parameters packs and identity elements.

Thanks for your answer and your time anyway! :)

Morwenn

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

<div dir=3D"ltr">Le lundi 17 novembre 2014 23:46:31 UTC+1, Jens Maurer a =
=C3=A9crit&nbsp;:&nbsp;<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Regardi=
ng "some operators": Which ones are missing, in your opinion?
<br></blockquote><div><br>That's a case of poor formulation: with "some ope=
rators", I meant that<br>operators are no more than "regular" binary functi=
ons with some sugar<br>added. It boils down to "some functions".<br>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Regarding "any binary fun=
ction": Yes, it's possible to make that work.
<br>I believe the original author has no intent to make this more general,
<br>so if you wish to go ahead, feel free to propose that. &nbsp;I'd like t=
o see
<br>some investigation into the issue whether &nbsp;(args f ...) &nbsp; (wh=
ere "f" is
<br>the name of an arbitrary function) could be syntactically confused with
<br>a part of a varargs function declaration.
<br></blockquote><div><br>Well, I am investing things. Actually, me creatin=
g this topic was also to<br>make things clearer in my head by writing them =
down. Your question is<br>interesting though. <br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">Don't do that, then.
<br></blockquote><div><br>I have no problem not doing it, but I have concer=
ns about whether always<br>defaulting (args + ...) to an integer when the p=
arameter pack is empty may<br>be the source of silent conversions and silen=
t problems. Instead of giving<br>privileges to integers alone, I would almo=
st prefere the program to be<br>ill-formed when an empty parameter pack is =
given to a fold expression<br>rather than having silent problems. Even for =
integers, the expression<br>(args + ...) can trivially be converted to (arg=
s + ... + 0) anyway. Not having<br>the special cases for some operators can=
 avoid silent and tricky problems.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">This is an awful lot of machinery, and adds more dependen=
cies from the
<br>core language to the standard library. &nbsp;What's the problem we actu=
ally
<br>need to solve? Is it so hard to write an additional overload for the
<br>empty pack case? &nbsp;Example:
<br>
<br>
<br>my_type f()
<br>{
<br>&nbsp; return my_type(); &nbsp;// or whatever the identity element is
<br>}
<br>
<br>template&lt;class ... T&gt;
<br>my_type f(T... x)
<br>{
<br>&nbsp; return (x my_fold_operation ...);
<br>}
<br>
<br>This also addresses the left_identity / right_identity issue.
<br></blockquote><div><br>I thought of two solutions to make "some built-in=
 types" and "user-defined types"<br>equal regarding the (args + ...) case. =
The first solution was to always make the<br>program ill-formed as explaine=
d a little bit earlier in this post. The second solution<br>was to come up =
with a generic solution that could work if sufficient information is<br>giv=
en. And I have to agree, it resulted in an awful lot of machinery.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; One problem however =
is that this solution only works with template functors. It did
<br>&gt; not manage to find a way to have this solution interact nicely wit=
h the operators
<br>&gt; and the other non-object functions.
<br>
<br>What do you mean with "non-object" functions?
<br>You already used std::multiplies in your syntax above, instead of "*",
<br>what the user actually wrote in the fold expression. &nbsp;How is that
<br>mapping going to happen?<br></blockquote><div><br>That's the problem I =
had: it is possible to specialize a template for a type or<br>for a templat=
e (this is why I used std::multiplies) but it is not possible to<br>special=
ize a template for a "function name" such as operator*. The mapping is<br>i=
ndeed a problem that could only be solved with compiler magic and that's no=
t<br>elegant. <br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So=
 far, I'm not convinced the specification and implementation cost outweighs
<br>the benefits. &nbsp;The N4295 restrictions were carefully crafted to ke=
ep these costs
<br>low.<br></blockquote><div><br>I have to agree that the implementation c=
osts are too high. But why I understand<br>the restrictions of N4295, I sti=
ll feel that the rules for empty parameter packs are<br>too strict (only wo=
rk with some types) and may introduce problems (silent conversion<br>of a t=
ype from a integer. Fortunately, standard types generally have explicit con=
structors<br>when they take only one parameter but not all libraries do tha=
t properly. Imagine a<br>sum function that only returns (args + ...). If yo=
u give it some array type with a<br>non-explicit size_type constructor and =
and operator+ for concatenation, you're up<br>for some surprises. The stand=
ard types don't have these pitfalls, but there are obviously<br>some librar=
ies around that do. My point is that this is not very type-safe. The type-s=
afe<br>solutions I thought of were either removing the special cases for em=
pty parameters or<br>creating a generic type-safe solutions, but it proved =
too hard/unpractical.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Also, I'm wondering whether one of the other proposals that try to ma=
ke
<br>template parameter packs more accessible would help address this in any=
 way.
<br>
<br>Jens<br></blockquote><div>&nbsp;<br>I also hope that some other templat=
e parameter pack proposal will offer other solutions :)<br>Meanwhile, I am =
developping a small library with fold funtions to check what I can<br>ultim=
etely do with regards to empty parameters packs and identity elements.<br><=
br>Thanks for your answer and your time anyway! :)<br><br>Morwenn<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_2420_675565925.1416324292982--

.

On 11/18/2014 04:24 PM, Ed wrote:
> I have no problem not doing it, but I have concerns about whether always
> defaulting (args + ...) to an integer when the parameter pack is empty may
> be the source of silent conversions and silent problems. Instead of giving
> privileges to integers alone, I would almost prefere the program to be
> ill-formed when an empty parameter pack is given to a fold expression
> rather than having silent problems. Even for integers, the expression
> (args + ...) can trivially be converted to (args + ... + 0) anyway. Not having
> the special cases for some operators can avoid silent and tricky problems.

It seems that ship is about to sail; in Urbana, WG21 agreed to take the
defaults for the small set of operators where they are provided.
I agree the default for "+" might be slightly icky (thinking about string
concatenation or vector-add), but I'm all in favor of the defaults for &&
and ||.  Writing "true &&" or "false ||" seems excessive syntax for the
common case.

On the other hand, for generic functions taking packs and using fold
expressions internally, the coding rule must be "never rely on the
default if you don't know what the element types of your pack are".

> I have to agree that the implementation costs are too high. But why I understand
> the restrictions of N4295, I still feel that the rules for empty parameter packs are
> too strict (only work with some types) and may introduce problems (silent conversion
> of a type from a integer. Fortunately, standard types generally have explicit constructors
> when they take only one parameter but not all libraries do that properly. Imagine a
> sum function that only returns (args + ...). If you give it some array type with a
> non-explicit size_type constructor and and operator+ for concatenation, you're up
> for some surprises. The standard types don't have these pitfalls, but there are obviously
> some libraries around that do.

I'm not sure about the "obvious" part.  Those libraries appear to be broken.
"explicit" has been around for quite a while, as well as the expertise when
to use it, at a minimum.

>   My point is that this is not very type-safe. The type-safe
> solutions I thought of were either removing the special cases for empty parameters or
> creating a generic type-safe solutions, but it proved too hard/unpractical.

So, given that a generic solution is "an awful lot of machinery", the other
way forward would be to remove the defaults for all but the && and || operators,
thereby leaving the design space open?

Jens

--

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

Le mardi 18 novembre 2014 20:54:50 UTC+1, Jens Maurer a =C3=A9crit :

> So, given that a generic solution is "an awful lot of machinery", the=20
> other=20
> way forward would be to remove the defaults for all but the && and ||=20
> operators,=20
> thereby leaving the design space open?=20
>
> Jens=20
>

That's more or less what I thought. The only operators where I would have=
=20
left
the defaults are operator&&, operator|| but also operator, since they
generally have the same semantics and overloading any of them is considered
bad practice anyway (and I don't like having to write void() explicitly=20
either).
The only place where overloading them might make sense in my opinion is in
the realm of expression templates and EDSL (agreed, Boost is known to
overload operator, but even the place where it is used is superseded by
initializer lists).

I have nothing to add to your other remarks. As you said, the ship is about=
=20
to
sail, but removing things from the draft before the standarization is not=
=20
unheard
of either. I will pursue my library experiments but, should something happe=
n
before C++17, I would rather see see only operator&&, operator|| and
operator, left as defaults.

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

<div dir=3D"ltr">Le mardi 18 novembre 2014 20:54:50 UTC+1, Jens Maurer a =
=C3=A9crit&nbsp;:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So, given=
 that a generic solution is "an awful lot of machinery", the other
<br>way forward would be to remove the defaults for all but the &amp;&amp; =
and || operators,
<br>thereby leaving the design space open?
<br>
<br>Jens
<br></blockquote><div><br>That's more or less what I thought. The only oper=
ators where I would have left<br>the defaults are <span style=3D"font-famil=
y: courier new,monospace;">operator&amp;&amp;</span>, <span style=3D"font-f=
amily: courier new,monospace;">operator||</span> but also <span style=3D"fo=
nt-family: courier new,monospace;">operator,</span> since they<br>generally=
 have the same semantics and overloading any of them is considered<br>bad p=
ractice anyway (and I don't like having to write <span style=3D"font-family=
: courier new,monospace;">void()</span> explicitly either).<br>The only pla=
ce where overloading them might make sense in my opinion is in<br>the realm=
 of expression templates and EDSL (agreed, Boost is known to<br>overload <s=
pan style=3D"font-family: courier new,monospace;">operator,</span> but even=
 the place where it is used is superseded by<br>initializer lists).<br><br>=
I have nothing to add to your other remarks. As you said, the ship is about=
 to<br>sail, but removing things from the draft before the standarization i=
s not unheard<br>of either. I will pursue my library experiments but, shoul=
d something happen<br>before C++17, I would rather see see only <span style=
=3D"font-family: courier new,monospace;">operator&amp;&amp;</span>, <span s=
tyle=3D"font-family: courier new,monospace;">operator||</span> and<br><span=
 style=3D"font-family: courier new,monospace;">operator,</span> left as def=
aults.<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_717_1270832215.1416342134220--

.

On 11/18/2014 09:22 PM, Ed wrote:
> That's more or less what I thought. The only operators where I would have left
> the defaults are operator&&, operator|| but also operator, since they
> generally have the same semantics and overloading any of them is considered
> bad practice anyway (and I don't like having to write void() explicitly either).
> The only place where overloading them might make sense in my opinion is in
> the realm of expression templates and EDSL (agreed, Boost is known to
> overload operator, but even the place where it is used is superseded by
> initializer lists).
>
> I have nothing to add to your other remarks. As you said, the ship is about to
> sail, but removing things from the draft before the standarization is not unheard
> of either. I will pursue my library experiments but, should something happen
> before C++17, I would rather see see only operator&&, operator|| and
> operator, left as defaults.

This will need a paper for the next WG21 meeting in Lenexa,
with arguments why it's harmful / not helpful to have the defaults for
the other operators.

Jens

--

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

Le mardi 18 novembre 2014 21:33:00 UTC+1, Jens Maurer a =C3=A9crit :

> This will need a paper for the next WG21 meeting in Lenexa,=20
> with arguments why it's harmful / not helpful to have the defaults for=20
> the other operators.=20
>
> Jens=20
>

Well, I guessed so... I might some time to try to find cases where it
could be harmful (yeah, it can be useful, but the problem is that it may
also be harmful) and to write something about. But I have neither the
time nor the money to go to the USA to attend a standard committee
meeting. Unless I manage to find some concrete cases where it might
indeed be harmful and find someone to champion the idea, I doubt that
it will get anywhere.

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

<div dir=3D"ltr">Le mardi 18 novembre 2014 21:33:00 UTC+1, Jens Maurer a =
=C3=A9crit&nbsp;:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This will=
 need a paper for the next WG21 meeting in Lenexa,
<br>with arguments why it's harmful / not helpful to have the defaults for
<br>the other operators.
<br>
<br>Jens
<br></blockquote><div><br>Well, I guessed so... I might some time to try to=
 find cases where it<br>could be harmful (yeah, it can be useful, but the p=
roblem is that it may<br>also be harmful) and to write something about. But=
 I have neither the<br>time nor the money to go to the USA to attend a stan=
dard committee<br>meeting. Unless I manage to find some concrete cases wher=
e it might<br>indeed be harmful and find someone to champion the idea, I do=
ubt that<br>it will get anywhere.<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_4896_165406783.1416344787784--

.

On 11/18/2014 10:06 PM, Ed wrote:
> Le mardi 18 novembre 2014 21:33:00 UTC+1, Jens Maurer a =C3=A9crit :
>=20
>     This will need a paper for the next WG21 meeting in Lenexa,
>     with arguments why it's harmful / not helpful to have the defaults fo=
r
>     the other operators.
>=20
>     Jens
>=20
>=20
> Well, I guessed so... I might some time to try to find cases where it
> could be harmful (yeah, it can be useful, but the problem is that it may
> also be harmful) and to write something about. But I have neither the
> time nor the money to go to the USA to attend a standard committee
> meeting.

I can certainly present your paper, but the issue doesn't bother me
enough to write one of my own.

>  Unless I manage to find some concrete cases where it might
> indeed be harmful=20

Well, we've already discussed a few.  Another idea:  Assume you
have a list type (lists of integers), and "+" is list concatenation.
Assume that there is an implicit conversion from "int" to "list with
one element".  Then  (args + ...)  concatenates all the lists in
"args", but for empty "args", it doesn't give the empty list (as it
should), instead it gives  { 0 }.  Surprising, I'd say.

Jens

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

Ok, here is a first draft. I believe that many things are to be corrected,
but at least it gives a rough idea:

https://github.com/Morwenn/Fold-expressions-proposal/blob/master/folding.pdf

--

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

<div dir=3D"ltr">Ok, here is a first draft. I believe that many things are =
to be corrected, but at least it gives a rough idea:<br><br><a href=3D"http=
s://github.com/Morwenn/Fold-expressions-proposal/blob/master/folding.pdf">h=
ttps://github.com/Morwenn/Fold-expressions-proposal/blob/master/folding.pdf=
</a><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_88_163528137.1416410980749--

.

Jens Maurer <Jens.Maurer@gmx.net> writes:

[...]

| It seems that ship is about to sail; in Urbana, WG21 agreed to take the
| defaults for the small set of operators where they are provided.
| I agree the default for "+" might be slightly icky (thinking about string
| concatenation or vector-add), but I'm all in favor of the defaults for &&
| and ||.  Writing "true &&" or "false ||" seems excessive syntax for the
| common case.

I am (not just "was") in favor of the fold expression proposal as it was
presented for vote because that took away a roadblock, and we could make
progress on concepts.

It is clear we need fold expression in face of variadic templates,
concepts or not; concepts just make the pain more obvious.  It is also
unquestionable that we can do better than what the proposal that was up
for votes at Urbana.  I did raise some concerns about "|" but I also
made it clear that it should be a CWG issue to clarify later, and we
needed to make progress.

Now that the notion of "fold expression" is acquired, we must not forget
that the "defaults" make sense only for the builtin types.  We have to
make it work for overloaded operators, including "&&" and "||".  Once we
have concepts -- and this was made for concepts -- it should be clear
that we *must* make them work for overloaded operators and, in general,
for binary functions.  The fact that we distinguish between those today
is an arbitrary restriction to get us started.  The restrictions aren't
fundamental.

-- Gaby

--

---
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_359_1911401930.1416842814434
Content-Type: multipart/alternative;
 boundary="----=_Part_360_724362037.1416842814434"

------=_Part_360_724362037.1416842814434
Content-Type: text/plain; charset=UTF-8

I believe that I am done writing the proposal. I included the scope, the
motivation, the wording, and also some discussion.
Now, unless you have something to add here, all that is left is to get a
proposal number. However, I can't find instructions
about how to do so. Everything is clear for library proposals, but I can't
find any help about how to get a number and submit
a core or evolution proposal (would this proposal fit into code or
evolution?). For some reason, lwgchair at gmail dot com
does not seem like the right place to ask. Can anyone help me with this?

--

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

<div dir=3D"ltr">I believe that I am done writing the proposal. I included =
the scope, the motivation, the wording, and also some discussion.<br>Now, u=
nless you have something to add here, all that is left is to get a proposal=
 number. However, I can't find instructions<br>about how to do so. Everythi=
ng is clear for library proposals, but I can't find any help about how to g=
et a number and submit<br>a core or evolution proposal (would this proposal=
 fit into code or evolution?). For some reason, lwgchair at gmail dot com<b=
r>does not seem like the right place to ask. Can anyone help me with this?<=
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_360_724362037.1416842814434--
------=_Part_359_1911401930.1416842814434--

.

2014-11-24 16:26 GMT+01:00 Ed <morwenn29@gmail.com>:
> I believe that I am done writing the proposal. I included the scope, the
> motivation, the wording, and also some discussion.
> Now, unless you have something to add here, all that is left is to get a
> proposal number. However, I can't find instructions
> about how to do so. Everything is clear for library proposals, but I can't
> find any help about how to get a number and submit
> a core or evolution proposal (would this proposal fit into code or
> evolution?). For some reason, lwgchair at gmail dot com
> does not seem like the right place to ask. Can anyone help me with this?

I agree that this is badly documented, but your right place is indeed
the lwgchair address. Note that you have just missed the recent
deadline of the post-meeting mailing (2014-11-21, for the most recent
date see always this page:

http://www.open-std.org/jtc1/sc22/wg21/
).

- Daniel

--

---
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_372_1809616971.1416844087340
Content-Type: multipart/alternative;
 boundary="----=_Part_373_1569022783.1416844087340"

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

Thanks for the quick reply :)

I still have time to think a bit about it then. I will submit it for the=20
pre-Lexena
mailing when it opens.

Le lundi 24 novembre 2014 16:31:04 UTC+1, Daniel Kr=C3=BCgler a =C3=A9crit =
:
>
> 2014-11-24 16:26 GMT+01:00 Ed <morw...@gmail.com <javascript:>>:=20
> > I believe that I am done writing the proposal. I included the scope, th=
e=20
> > motivation, the wording, and also some discussion.=20
> > Now, unless you have something to add here, all that is left is to get =
a=20
> > proposal number. However, I can't find instructions=20
> > about how to do so. Everything is clear for library proposals, but I=20
> can't=20
> > find any help about how to get a number and submit=20
> > a core or evolution proposal (would this proposal fit into code or=20
> > evolution?). For some reason, lwgchair at gmail dot com=20
> > does not seem like the right place to ask. Can anyone help me with this=
?=20
>
> I agree that this is badly documented, but your right place is indeed=20
> the lwgchair address. Note that you have just missed the recent=20
> deadline of the post-meeting mailing (2014-11-21, for the most recent=20
> date see always this page:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/=20
> ).=20
>
> - Daniel=20
>

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

<div dir=3D"ltr">Thanks for the quick reply :)<br><br>I still have time to =
think a bit about it then. I will submit it for the pre-Lexena<br>mailing w=
hen it opens.<br><br>Le lundi 24 novembre 2014 16:31:04 UTC+1, Daniel Kr=C3=
=BCgler a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">201=
4-11-24 16:26 GMT+01:00 Ed &lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"Ej8THyoHpfMJ" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">morw...=
@gmail.com</a>&gt;:
<br>&gt; I believe that I am done writing the proposal. I included the scop=
e, the
<br>&gt; motivation, the wording, and also some discussion.
<br>&gt; Now, unless you have something to add here, all that is left is to=
 get a
<br>&gt; proposal number. However, I can't find instructions
<br>&gt; about how to do so. Everything is clear for library proposals, but=
 I can't
<br>&gt; find any help about how to get a number and submit
<br>&gt; a core or evolution proposal (would this proposal fit into code or
<br>&gt; evolution?). For some reason, lwgchair at gmail dot com
<br>&gt; does not seem like the right place to ask. Can anyone help me with=
 this?
<br>
<br>I agree that this is badly documented, but your right place is indeed
<br>the lwgchair address. Note that you have just missed the recent
<br>deadline of the post-meeting mailing (2014-11-21, for the most recent
<br>date see always this page:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/" target=3D"_blank" o=
nmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNEDzT=
C8Ry9aTHT3x4t5uwkCZP6E8A';return true;" onclick=3D"this.href=3D'http://www.=
google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F\46=
sa\75D\46sntz\0751\46usg\75AFQjCNEDzTC8Ry9aTHT3x4t5uwkCZP6E8A';return true;=
">http://www.open-std.org/jtc1/<wbr>sc22/wg21/</a>
<br>).
<br>
<br>- Daniel
<br></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_373_1569022783.1416844087340--
------=_Part_372_1809616971.1416844087340--

.

------=_Part_8652_1782497998.1417263307013
Content-Type: multipart/alternative;
 boundary="----=_Part_8653_1046976736.1417263307013"

------=_Part_8653_1046976736.1417263307013
Content-Type: text/plain; charset=UTF-8

By the way, I just noticed that operator~ can be used in a fold expression.
That' an unary operator, hardly usable in a fold. Isn't that an error?

--

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

<div dir="ltr">By the way, I just noticed that <span style="font-family: courier new,monospace;">operator~</span> can be used in a fold expression.<br>That' an unary operator, hardly usable in a fold. Isn't that an error?<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_8653_1046976736.1417263307013--
------=_Part_8652_1782497998.1417263307013--

.

--bcaec548610a60c1d80509058eca
Content-Type: text/plain; charset=UTF-8

On 29 Nov 2014 04:15, "Ed" <morwenn29@gmail.com> wrote:
>
> By the way, I just noticed that operator~ can be used in a fold
expression.
> That' an unary operator, hardly usable in a fold. Isn't that an error?

Yes, that was an error; it was corrected in the paper that got voted into
the writing draft (see the paper in the post-meeting mailing).

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--bcaec548610a60c1d80509058eca
Content-Type: text/html; charset=UTF-8

<p dir="ltr">On 29 Nov 2014 04:15, &quot;Ed&quot; &lt;<a href="mailto:morwenn29@gmail.com">morwenn29@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; By the way, I just noticed that operator~ can be used in a fold expression.<br>
&gt; That&#39; an unary operator, hardly usable in a fold. Isn&#39;t that an error?</p>
<p dir="ltr">Yes, that was an error; it was corrected in the paper that got voted into the writing draft (see the paper in the post-meeting mailing).</p>
<p dir="ltr">&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; 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>
</p>

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

--bcaec548610a60c1d80509058eca--

.

------=_Part_5639_1550975397.1417362241259
Content-Type: multipart/alternative;
 boundary="----=_Part_5640_399108022.1417362241265"

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



Le samedi 29 novembre 2014 21:52:33 UTC+1, Richard Smith a =C3=A9crit :
>
> On 29 Nov 2014 04:15, "Ed" <morw...@gmail.com <javascript:>> wrote:
> >
> > By the way, I just noticed that operator~ can be used in a fold=20
> expression.
> > That' an unary operator, hardly usable in a fold. Isn't that an error?
>
> Yes, that was an error; it was corrected in the paper that got voted into=
=20
> the writing draft (see the paper in the post-meeting mailing).
>
If you're talking about N4295, operator~ is still there. I realize that it=
=20
has been removed from the draft on Github, though :)

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

<div dir=3D"ltr"><br><br>Le samedi 29 novembre 2014 21:52:33 UTC+1, Richard=
 Smith a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p d=
ir=3D"ltr">On 29 Nov 2014 04:15, "Ed" &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"tVDRjPWxmc4J" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">morw...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; By the way, I just noticed that operator~ can be used in a fold expres=
sion.<br>
&gt; That' an unary operator, hardly usable in a fold. Isn't that an error?=
</p>
<p dir=3D"ltr">Yes, that was an error; it was corrected in the paper that g=
ot voted into the writing draft (see the paper in the post-meeting mailing)=
..</p></blockquote><div>If you're talking about N4295, <span style=3D"font-f=
amily: courier new,monospace;">operator~</span> is still there. I realize t=
hat it has been removed from the draft on Github, though :)<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_5640_399108022.1417362241265--
------=_Part_5639_1550975397.1417362241259--

.

--001a11c28b16bed3eb05091a9c3b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 30, 2014 at 7:44 AM, Ed <morwenn29@gmail.com> wrote:

> Le samedi 29 novembre 2014 21:52:33 UTC+1, Richard Smith a =C3=A9crit :
>>
>> On 29 Nov 2014 04:15, "Ed" <morw...@gmail.com> wrote:
>> >
>> > By the way, I just noticed that operator~ can be used in a fold
>> expression.
>> > That' an unary operator, hardly usable in a fold. Isn't that an error?
>>
>> Yes, that was an error; it was corrected in the paper that got voted int=
o
>> the writing draft (see the paper in the post-meeting mailing).
>>
> If you're talking about N4295, operator~ is still there. I realize that
> it has been removed from the draft on Github, though :)
>

Oh, it looks like the paper in the post-meeting mailing is not actually the
right one (the wording that was voted on at Urbana had the ~ removed as a
fairly late change, and the paper in the mailing is missing that change).

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

--001a11c28b16bed3eb05091a9c3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Nov 30, 2014 at 7:44 AM, Ed <span dir=3D"ltr">&lt;<a href=3D"mailto:mor=
wenn29@gmail.com" target=3D"_blank">morwenn29@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Le samedi 29 novembre=
 2014 21:52:33 UTC+1, Richard Smith a =C3=A9crit=C2=A0:<span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">On 29 Nov 2014 04:15, &=
quot;Ed&quot; &lt;<a>morw...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; By the way, I just noticed that operator~ can be used in a fold expres=
sion.<br>
&gt; That&#39; an unary operator, hardly usable in a fold. Isn&#39;t that a=
n error?</p>
<p dir=3D"ltr">Yes, that was an error; it was corrected in the paper that g=
ot voted into the writing draft (see the paper in the post-meeting mailing)=
..</p></blockquote></span><div>If you&#39;re talking about N4295, <span styl=
e=3D"font-family:courier new,monospace">operator~</span> is still there. I =
realize that it has been removed from the draft on Github, though :)</div><=
/div></blockquote><div><br></div><div>Oh, it looks like the paper in the po=
st-meeting mailing is not actually the right one (the wording that was vote=
d on at Urbana had the ~ removed as a fairly late change, and the paper in =
the mailing is missing that change).</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />

--001a11c28b16bed3eb05091a9c3b--

.

------=_Part_2076_1911763794.1430050918863
Content-Type: multipart/alternative;
 boundary="----=_Part_2077_363759344.1430050918864"

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

Le mardi 18 novembre 2014 23:29:38 UTC+1, Jens Maurer a =C3=A9crit :
>
> I can certainly present your paper, but the issue doesn't bother me=20
> enough to write one of my own.
>

Are you still ok to present the paper (N4358) during the Lenexa meeting in=
=20
my stead?=20

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

<div dir=3D"ltr">Le mardi 18 novembre 2014 23:29:38 UTC+1, Jens Maurer a =
=C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I can certain=
ly present your paper, but the issue doesn't bother me
<br>enough to write one of my own.<br></blockquote><div><br>Are you still o=
k to present the paper (N4358) during the Lenexa meeting in my stead? <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_2077_363759344.1430050918864--
------=_Part_2076_1911763794.1430050918863--

.