Topic: N3617 - Making C++ more functional


Author: Xeo <hivemaster@hotmail.de>
Date: Sun, 21 Apr 2013 11:04:15 -0700 (PDT)
Raw View
------=_Part_1295_23391002.1366567455446
Content-Type: text/plain; charset=ISO-8859-1

Linked below is a proposal to open up C++ more to functional programming,
by introducing a technique to allow what functional languages naturally
have - passing functions by their name. It was formerly called "Lifting
overload sets into function objects", but that describes just one of the
things it does, not what it brings, so I changed the name.

Discussions and ideas are more than welcome.

N3617 - Making C++ more functional<https://dl.dropboxusercontent.com/u/14327987/functional_cpp.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/?hl=en.



------=_Part_1295_23391002.1366567455446
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Linked below is a proposal to open up C++ more to functional programming, b=
y introducing a technique to allow what functional languages naturally have=
 - passing functions by their name. It was formerly called "Lifting overloa=
d sets into function objects", but that describes just one of the things it=
 does, not what it brings, so I changed the name.<br><br>Discussions and id=
eas are more than welcome.<br><br><a href=3D"https://dl.dropboxusercontent.=
com/u/14327987/functional_cpp.html">N3617 - Making C++ more functional</a><=
br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1295_23391002.1366567455446--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 21 Apr 2013 15:55:46 -0700 (PDT)
Raw View
------=_Part_712_10321484.1366584946667
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, April 21, 2013 11:04:15 AM UTC-7, Xeo wrote:
>
> Linked below is a proposal to open up C++ more to functional programming,
> by introducing a technique to allow what functional languages naturally
> have - passing functions by their name. It was formerly called "Lifting
> overload sets into function objects", but that describes just one of the
> things it does, not what it brings, so I changed the name.
>
> Discussions and ideas are more than welcome.
>
> N3617 - Making C++ more functional<https://dl.dropboxusercontent.com/u/14327987/functional_cpp.html>
>

OK, that's not N3617, and it's not a good idea to misrepresent an *edited*version for the official
proposal document<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm>
..

I'll be discussing the official proposal, not your edited one.

It should be noted that `[]id-expression` is something that terse template
concept syntax is kind of wanting to use too. And we may want
`[]id-expression` to be a way of defining functions in the future. In
short, there's some contention for this grammar.

--

---
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/?hl=en.



------=_Part_712_10321484.1366584946667
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sunday, April 21, 2013 11:04:15 AM UTC-7, Xeo wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">Linked below is a proposal to open up C++ more to =
functional programming, by introducing a technique to allow what functional=
 languages naturally have - passing functions by their name. It was formerl=
y called "Lifting overload sets into function objects", but that describes =
just one of the things it does, not what it brings, so I changed the name.<=
br><br>Discussions and ideas are more than welcome.<br><br><a href=3D"https=
://dl.dropboxusercontent.com/u/14327987/functional_cpp.html" target=3D"_bla=
nk">N3617 - Making C++ more functional</a><br></blockquote><div><br>OK, tha=
t's not N3617, and it's not a good idea to misrepresent an <i>edited</i> ve=
rsion for the <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers=
/2013/n3617.htm">official proposal document</a>.<br><br>I'll be discussing =
the official proposal, not your edited one.<br><br>It should be noted that =
`[]id-expression` is something that terse template concept syntax is kind o=
f wanting to use too. And we may want `[]id-expression` to be a way of defi=
ning functions in the future. In short, there's some contention for this gr=
ammar.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_712_10321484.1366584946667--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 22 Apr 2013 02:12:36 +0300
Raw View
--089e013a0a1e84b2a204dae716dd
Content-Type: text/plain; charset=ISO-8859-1

On 22 April 2013 01:55, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Sunday, April 21, 2013 11:04:15 AM UTC-7, Xeo wrote:
>>
>> Linked below is a proposal to open up C++ more to functional programming,
>> by introducing a technique to allow what functional languages naturally
>> have - passing functions by their name. It was formerly called "Lifting
>> overload sets into function objects", but that describes just one of the
>> things it does, not what it brings, so I changed the name.
>>
>> Discussions and ideas are more than welcome.
>>
>> N3617 - Making C++ more functional<https://dl.dropboxusercontent.com/u/14327987/functional_cpp.html>
>>
>
> OK, that's not N3617, and it's not a good idea to misrepresent an *edited*version for the official
> proposal document<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm>
> .
>
>
Sigh. Do NOT, NOT _EVER_

1) publish an N-numbered document if it's not identical to one that appears
or will appear in a mailing
2) edit(*) an N-numbered document after it's been in a mailing. If you want
to create a new version,
get a new number, and publish it with a d-number (which should still match
the allocated number, if
any, or just make it dxxx.html) if you want to float around working
revisions.

(1) If the INCITS vice chair requests you to eg. add a date to the
document, that's ok to edit in.
Even in that case, make SURE you only ever publish one version, the last,
of an N-number document.

--

---
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/?hl=en.



--089e013a0a1e84b2a204dae716dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 22 April 2013 01:55, Nicol Bolas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sunday, April 21, 2013 =
11:04:15 AM UTC-7, Xeo wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Linked below is a proposal to open up C++ more to functional programming, b=
y introducing a technique to allow what functional languages naturally have=
 - passing functions by their name. It was formerly called &quot;Lifting ov=
erload sets into function objects&quot;, but that describes just one of the=
 things it does, not what it brings, so I changed the name.<br>
<br>Discussions and ideas are more than welcome.<br><br><a href=3D"https://=
dl.dropboxusercontent.com/u/14327987/functional_cpp.html" target=3D"_blank"=
>N3617 - Making C++ more functional</a><br></blockquote></div><div><br>OK, =
that&#39;s not N3617, and it&#39;s not a good idea to misrepresent an <i>ed=
ited</i> version for the <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/=
docs/papers/2013/n3617.htm" target=3D"_blank">official proposal document</a=
>.<br>
<br></div></blockquote><div><br></div><div>Sigh. Do NOT, NOT _EVER_<br><br>=
</div><div>1) publish an N-numbered document if it&#39;s not identical to o=
ne that appears or will appear in a mailing<br></div><div>2) edit(*) an N-n=
umbered document after it&#39;s been in a mailing. If you want to create a =
new version,<br>
get a new number, and publish it with a d-number (which should still match =
the allocated number, if<br>any, or just make it dxxx.html) if you want to =
float around working revisions.<br></div></div><br></div><div class=3D"gmai=
l_extra">
(1) If the INCITS vice chair requests you to eg. add a date to the document=
, that&#39;s ok to edit in.<br></div><div class=3D"gmail_extra">Even in tha=
t case, make SURE you only ever publish one version, the last, of an N-numb=
er document.<br>
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e013a0a1e84b2a204dae716dd--

.


Author: Xeo <hivemaster@hotmail.de>
Date: Sun, 21 Apr 2013 23:04:18 -0700 (PDT)
Raw View
------=_Part_711_7810675.1366610658508
Content-Type: text/plain; charset=ISO-8859-1

On Monday, April 22, 2013 1:12:36 AM UTC+2, Ville Voutilainen wrote:
>
>
> Sigh. Do NOT, NOT _EVER_
>
> 1) publish an N-numbered document if it's not identical to one that
> appears or will appear in a mailing
>
My bad, will not happen again.


> 2) edit(*) an N-numbered document after it's been in a mailing. If you
> want to create a new version,
> get a new number, and publish it with a d-number (which should still match
> the allocated number, if
> any, or just make it dxxx.html) if you want to float around working
> revisions.
>
Will do. Should I open a new thread and delete this one to avoid further
confusion?

--

---
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/?hl=en.



------=_Part_711_7810675.1366610658508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Monday, April 22, 2013 1:12:36 AM UTC+2, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><br><div>Sigh. Do NOT, NOT _EVER_<br><br></div><div>1) publish =
an N-numbered document if it's not identical to one that appears or will ap=
pear in a mailing<br></div></div></div></div></blockquote><div>My bad, will=
 not happen again.<br>&nbsp;</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><div class=3D"gmail_quote"><div></div><div>2) e=
dit(*) an N-numbered document after it's been in a mailing. If you want to =
create a new version,<br>
get a new number, and publish it with a d-number (which should still match =
the allocated number, if<br>any, or just make it dxxx.html) if you want to =
float around working revisions.<br></div></div></div></div></blockquote><di=
v>Will do. Should I open a new thread and delete this one to avoid further =
confusion?<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_711_7810675.1366610658508--

.


Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Thu, 30 Jul 2015 07:24:20 -0700 (PDT)
Raw View
------=_Part_7008_1770034532.1438266260677
Content-Type: multipart/alternative;
 boundary="----=_Part_7009_1988051915.1438266260678"

------=_Part_7009_1988051915.1438266260678
Content-Type: text/plain; charset=UTF-8

Now that we are further down the line to generic lambdas I think this idea
is more natural. However I don't think we need any new syntax.

Currently &function can be used instead of a lambda, for instance as a
predicate.

Now with generic lambdas we can't use &function anymore as the function
would presumably be overloaded and thus not allowed to be substituted for a
template parameter.

So, what if it would be allowed? This is the same functionality as N3617
suggests but with a syntax that is very natural.

Initially I thought that the implementation would be really messy but after
reading N3617 I think it isn't:

In the current case that a overloaded function is sent as an actual for a
templated parameter, create a wrapper class with template operator()
similar to what a generic lambda does.

This implements the call by name semantics and it should be rather easy to
specify and implement thanks to machinery already required for generic
lambdas.

As it only kicks in in a situation which is currently an error I don't
think it would be dangerous.

Example:

void func(int a);
void func(float b);
void gunc(int b);

template<typename F, typename T> void apply(F f, T val) { f(val); }

// Expanded class (return type not auto as my compiler does not have auto
return deduction for functions).
class func__class {
    template<typename... T> void operator()(T&&... vals) { return
func(std::forward<T>(vals)...); }
};

void test()
{
    apply(&gunc, 1);

    // Does not work today
    apply(&func, 1);
    apply(&func, 3.14);

    // Result of rewrite which works in C++11-
    apply(func__class(), 1);
    apply(func__class(), 3.14);
}


Method overload sets should be transformed to make the analogy with a
non-overloaded method work. If you send &Class::Method to a function taking
it as a template parameter
the function body can do ->* or .* on it with some lhs convertible to
Class. Unfortunately there doesn't seem to be any way to hide the
overload-set into a class with a template operator() which preserves
the syntax of the call site. This would require relying on unified function
calling (UFC). Lets see:


class TestClass {
public:
void func(int a);
void func(float b);
void gunc(int b);
};


template<typename F, typename T> void applyMethod(F f, TestClass& obj, T
val) { obj.*f(val); }

// Expanded method class (return type not shown as my compiler does not
have auto return deduction for functions.
// This requires UFC to move the lhs argument of .* into the parameter list
and then allow a opeartor() to be called in lieu of a
// function.
class method__class {
template<typename... T> void operator()(TestClass& obj, T&&... vals) {
return obj.func(std::forward<T>(vals)...); }
};

void test2()
{
TestClass obj;

applyMethod(&TestClass::gunc, obj, 1);

// Does not work today
applyMethod(&TestClass::func, obj, 1);
applyMethod(&TestClass::func, obj, 3.14);

// Result of rewrite which does not work in C++11 due to lack of UFC.
apply(method__class(), obj, 1);
apply(method__class(), obj, 3.14);
}




This requires a fairly comprehensive UFC or some other compiler magic.
Maybe there is a smarter way of defining the rewrite but I haven't found
one. If handled by UFC it must be
available for .* and ->* as well as . and ->, furthermore it must play with
the rhs being an object with an operator() rather than a method pointer or
function pointer.

Method case seems to get very messy, and the applicability is much more
limited than for functions. My suggestion would be to focus only on
functions to get a reasonably simple proposal.


--

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

<div dir=3D"ltr">Now that we are further down the line to generic lambdas I=
 think this idea is more natural. However I don&#39;t think we need any new=
 syntax.<div><br></div><div>Currently &amp;function can be used instead of =
a lambda, for instance as a predicate.</div><div><br></div><div>Now with ge=
neric lambdas we can&#39;t use &amp;function anymore as the function would =
presumably be overloaded and thus not allowed to be substituted for a templ=
ate parameter.</div><div><br></div><div>So, what if it would be allowed? Th=
is is the same functionality as N3617 suggests but with a syntax that is ve=
ry natural.</div><div><br></div><div>Initially I thought that the implement=
ation would be really messy but after reading N3617 I think it isn&#39;t:</=
div><div><br></div><div>In the current case that a overloaded function is s=
ent as an actual for a templated parameter, create a wrapper class with tem=
plate operator() similar to what a generic lambda does.</div><div><br></div=
><div><div>This implements the call by name semantics and it should be rath=
er easy to specify and implement thanks to machinery already required for g=
eneric lambdas.<br></div><div><br></div><div>As it only kicks in in a situa=
tion which is currently an error I don&#39;t think it would be dangerous.</=
div><div><br></div><div>Example:</div><div><br></div><div><div class=3D"pre=
ttyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><div class=3D"subprettyprint"><div class=3D"subp=
rettyprint"><font color=3D"#660066">void func(int a);</font></div><div clas=
s=3D"subprettyprint"><font color=3D"#660066">void func(float b);</font></di=
v><div class=3D"subprettyprint"><font color=3D"#660066">void gunc(int b);</=
font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></font=
></div><div class=3D"subprettyprint"><font color=3D"#660066">template&lt;ty=
pename F, typename T&gt; void apply(F f, T val) { f(val); }</font></div><di=
v class=3D"subprettyprint"><font color=3D"#660066"><br></font></div><div cl=
ass=3D"subprettyprint"><font color=3D"#660066">// Expanded class (return ty=
pe not auto as my compiler does not have auto return deduction for function=
s).</font></div><div class=3D"subprettyprint"><font color=3D"#660066">class=
 func__class {</font></div><div class=3D"subprettyprint"><font color=3D"#66=
0066">=C2=A0 =C2=A0 template&lt;typename... T&gt; void operator()(T&amp;&am=
p;... vals) { return func(std::forward&lt;T&gt;(vals)...); }</font></div><d=
iv class=3D"subprettyprint"><font color=3D"#660066">};</font></div><div cla=
ss=3D"subprettyprint"><font color=3D"#660066"><br></font></div><div class=
=3D"subprettyprint"><font color=3D"#660066">void test()</font></div><div cl=
ass=3D"subprettyprint"><font color=3D"#660066">{</font></div><div class=3D"=
subprettyprint"><font color=3D"#660066">=C2=A0 =C2=A0 apply(&amp;gunc, 1);<=
/font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></fon=
t></div><div class=3D"subprettyprint"><font color=3D"#660066">=C2=A0 =C2=A0=
 // Does not work today</font></div><div class=3D"subprettyprint"><font col=
or=3D"#660066">=C2=A0 =C2=A0 apply(&amp;func, 1);</font></div><div class=3D=
"subprettyprint"><font color=3D"#660066">=C2=A0 =C2=A0 apply(&amp;func, 3.1=
4);</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br><=
/font></div><div class=3D"subprettyprint"><font color=3D"#660066">=C2=A0 =
=C2=A0 // Result of rewrite which works in C++11-</font></div><div class=3D=
"subprettyprint"><font color=3D"#660066">=C2=A0 =C2=A0 apply(func__class(),=
 1);</font></div><div class=3D"subprettyprint"><font color=3D"#660066">=C2=
=A0 =C2=A0 apply(func__class(), 3.14);</font></div><div class=3D"subprettyp=
rint"><font color=3D"#660066">}</font></div><div><br></div></div></div></co=
de></div></div><div><br></div><div>Method overload sets should be transform=
ed to make the analogy with a non-overloaded method work. If you send &amp;=
Class::Method to a function taking it as a template parameter</div><div>the=
 function body can do -&gt;* or .* on it with some lhs convertible to Class=
.. Unfortunately there doesn&#39;t seem to be any way to hide the overload-s=
et into a class with a template operator() which preserves</div><div>the sy=
ntax of the call site. This would require relying on unified function calli=
ng (UFC). Lets see:</div><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; backgrou=
nd-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><br></f=
ont></div><div class=3D"subprettyprint"><font color=3D"#660066">class TestC=
lass {</font></div><div class=3D"subprettyprint"><font color=3D"#660066">pu=
blic:</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void func(int=
 a);</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><spa=
n class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void func(floa=
t b);</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>void gunc(int=
 b);</font></div><div class=3D"subprettyprint"><font color=3D"#660066">};</=
font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></font=
></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></font></d=
iv><div class=3D"subprettyprint"><font color=3D"#660066">template&lt;typena=
me F, typename T&gt; void applyMethod(F f, TestClass&amp; obj, T val) { obj=
..*f(val); }</font></div><div class=3D"subprettyprint"><font color=3D"#66006=
6"><br></font></div><div class=3D"subprettyprint"><font color=3D"#660066">/=
/ Expanded method class (return type not shown as my compiler does not have=
 auto return deduction for functions.</font></div><div class=3D"subprettypr=
int"><font color=3D"#660066">// This requires UFC to move the lhs argument =
of .* into the parameter list and then allow a opeartor() to be called in l=
ieu of a</font></div><div class=3D"subprettyprint"><font color=3D"#660066">=
// function.</font></div><div class=3D"subprettyprint"><font color=3D"#6600=
66">class method__class {</font></div><div class=3D"subprettyprint"><font c=
olor=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>template&lt;typename... T&gt; void operator()(TestClass&amp; obj, T&=
amp;&amp;... vals) { return obj.func(std::forward&lt;T&gt;(vals)...); }</fo=
nt></div><div class=3D"subprettyprint"><font color=3D"#660066">};</font></d=
iv><div class=3D"subprettyprint"><font color=3D"#660066"><br></font></div><=
div class=3D"subprettyprint"><font color=3D"#660066">void test2()</font></d=
iv><div class=3D"subprettyprint"><font color=3D"#660066">{</font></div><div=
 class=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-=
span" style=3D"white-space:pre"> </span>TestClass obj;</font></div><div cla=
ss=3D"subprettyprint"><font color=3D"#660066"><br></font></div><div class=
=3D"subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"> </span>applyMethod(&amp;TestClass::gunc, obj, 1)=
;</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><br></f=
ont></div><div class=3D"subprettyprint"><font color=3D"#660066"><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>// Does not work toda=
y</font></div><div class=3D"subprettyprint"><font color=3D"#660066"><span c=
lass=3D"Apple-tab-span" style=3D"white-space:pre"> </span>applyMethod(&amp;=
TestClass::func, obj, 1);</font></div><div class=3D"subprettyprint"><font c=
olor=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>applyMethod(&amp;TestClass::func, obj, 3.14);</font></div><div class=
=3D"subprettyprint"><font color=3D"#660066"><br></font></div><div class=3D"=
subprettyprint"><font color=3D"#660066"><span class=3D"Apple-tab-span" styl=
e=3D"white-space:pre"> </span>// Result of rewrite which does not work in C=
++11 due to lack of UFC.</font></div><div class=3D"subprettyprint"><font co=
lor=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> <=
/span>apply(method__class(), obj, 1);</font></div><div class=3D"subprettypr=
int"><font color=3D"#660066"><span class=3D"Apple-tab-span" style=3D"white-=
space:pre"> </span>apply(method__class(), obj, 3.14);</font></div><div clas=
s=3D"subprettyprint"><font color=3D"#660066">}</font></div><div class=3D"su=
bprettyprint"><font color=3D"#660066"><br></font></div><div class=3D"subpre=
ttyprint"><br></div></div></code></div><br><br></div><div>This requires a f=
airly comprehensive UFC or some other compiler magic. Maybe there is a smar=
ter way of defining the rewrite but I haven&#39;t found one. If handled by =
UFC it must be</div></div><div>available for .* and -&gt;* as well as . and=
 -&gt;, furthermore it must play with the rhs being an object with an opera=
tor() rather than a method pointer or function pointer.</div><div><br></div=
><div>Method case seems to get very messy, and the applicability is much mo=
re limited than for functions. My suggestion would be to focus only on func=
tions to get a reasonably simple proposal.</div><div><br></div><div><br></d=
iv></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_7009_1988051915.1438266260678--
------=_Part_7008_1770034532.1438266260677--

.