------=_Part_105_14978464.1380556493888
Content-Type: text/plain; charset=ISO-8859-1

Hi, I have a wishlist of features I'd like to see discussed about, explored
and maybe pursued to see C++ evolve. I'll try to post them separately to
hopefully have them explored a bit.

I'd like to have some kind of true first-class function types or some
mechanism of declaring type constraints which specify & document to other
programmers what is expected of a callable entity parameter of template
function, when you have code like this:

template < typename Function, typename Tp >
auto foo(Function fn) -> Tp;

It's impossible to know what the expected parameter and return types must
be without looking at the definition of the function or trying to figure
them out from compile-errors, if you're lucky the author may have properly
documented what the types are but that's usually not the case especially
for projects that are still in flux.

Even with documentation this still isn't as good as having this as part of
the type system and having self-documenting code. I wish I could write C++
code something like this:

template < typename Tp >
auto foo(Tp fn(Tp)) -> Tp;

We have function signatures in C++, can we not make into them first-class
function types to some extent? If not maybe some mechisim to achieve
simlliar results using template constraints while still being readable,
self-documenting and able to produce comprehensible error messages when a
programmer makes a mistake.

--

---
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_105_14978464.1380556493888
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, I have a wishlist of features I'd like to see discusse=
d about, explored and maybe pursued to see C++ evolve. I'll try to post the=
m separately to hopefully have them explored a bit.<br><br>I'd like to have=
 some kind of true first-class function types or some mechanism of declarin=
g type constraints which specify &amp; document to other programmers what i=
s expected of a callable entity parameter of template function, when you ha=
ve code like this:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Tp</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Function</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> fn</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Tp</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>It's impossible to know what the expected parame=
ter and return types must be without looking at the definition of the funct=
ion or trying to figure them out from compile-errors, if you're lucky the a=
uthor may have properly documented what the types are but that's usually no=
t the case especially for projects that are still in flux.<br><br>Even with=
 documentation this still isn't as good as having this as part of the type =
system and having self-documenting code. I wish I could write C++ code some=
thing like this:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Tp</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Tp</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Tp</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Tp</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div><br>We have function signatures in C++, can we not=
 make into them first-class function types to some extent? If not maybe som=
e mechisim to achieve simlliar results using template constraints while sti=
ll being readable, self-documenting and able to produce comprehensible erro=
r messages when a programmer makes a mistake.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_105_14978464.1380556493888--

.

On segunda-feira, 30 de setembro de 2013 08:54:53, snk_kid wrote:
> Even with documentation this still isn't as good as having this as part of
> the type system and having self-documenting code. I wish I could write C++
> code something like this:
>
> template < typename Tp >
> auto foo(Tp fn(Tp)) -> Tp;

This compiles. So why can't you write C++ code like that?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_2928_8565587.1380559149508
Content-Type: text/plain; charset=ISO-8859-1

It compiles as a pointer/reference to function which is not exactly what I
meant or quite wanted, it's not as flexible as the first version of foo.

The first version would allow pointer/reference to function, a lambda
expression that does or does not capture lexical scope (closures), or
normal struct with a function call operator overloaded.

On Monday, September 30, 2013 5:22:58 PM UTC+1, Thiago Macieira wrote:
>
> On segunda-feira, 30 de setembro de 2013 08:54:53, snk_kid wrote:
> > Even with documentation this still isn't as good as having this as part
> of
> > the type system and having self-documenting code. I wish I could write
> C++
> > code something like this:
> >
> > template < typename Tp >
> > auto foo(Tp fn(Tp)) -> Tp;
>
> This compiles. So why can't you write C++ code like that?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
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_2928_8565587.1380559149508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It compiles as a pointer/reference to function which is no=
t exactly what I meant or quite wanted, it's not as flexible as the first v=
ersion of foo.<br><br>The first version would allow pointer/reference to fu=
nction, a lambda expression that does or does not capture lexical scope (cl=
osures), or normal struct with a function call operator overloaded.<br><br>=
On Monday, September 30, 2013 5:22:58 PM UTC+1, Thiago Macieira wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 30 de setembro de=
 2013 08:54:53, snk_kid wrote:
<br>&gt; Even with documentation this still isn't as good as having this as=
 part of=20
<br>&gt; the type system and having self-documenting code. I wish I could w=
rite C++=20
<br>&gt; code something like this:
<br>&gt;=20
<br>&gt; template &lt; typename Tp &gt;
<br>&gt; auto foo(Tp fn(Tp)) -&gt; Tp;
<br>
<br>This compiles. So why can't you write C++ code like that?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2928_8565587.1380559149508--

.

On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> It compiles as a pointer/reference to function which is not exactly what I
> meant or quite wanted, it's not as flexible as the first version of foo.
>
> The first version would allow pointer/reference to function, a lambda
> expression that does or does not capture lexical scope (closures), or
> normal struct with a function call operator overloaded.

That would be std::function.

template < typename Tp >
auto foo(std::function<Tp(Tp)>) -> Tp;

What are the deficiencies you see in std::function that would require making it
a first-class type?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--089e014946f461a6cb04e79d4453
Content-Type: text/plain; charset=ISO-8859-1

2013/9/30 Thiago Macieira <thiago@macieira.org>

> On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> > It compiles as a pointer/reference to function which is not exactly what
> I
> > meant or quite wanted, it's not as flexible as the first version of foo.
> >
> > The first version would allow pointer/reference to function, a lambda
> > expression that does or does not capture lexical scope (closures), or
> > normal struct with a function call operator overloaded.
>
> That would be std::function.
>
> template < typename Tp >
> auto foo(std::function<Tp(Tp)>) -> Tp;
>
> What are the deficiencies you see in std::function that would require
> making it
> a first-class type?
>

std::function is sometimes too slow (but as usual, that has to be proved on
a case-by-case basis, otherwise it's premature optimization).
I guess it might be possible to express such a template constraint using
some sort of concepts.

--

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

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

<div dir=3D"ltr">2013/9/30 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D=
"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;<=
/span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div class=3D"im">On segunda-feira, 30 de setembro de 2013 09:39:09, snk_ki=
d wrote:<br>
&gt; It compiles as a pointer/reference to function which is not exactly wh=
at I<br>
&gt; meant or quite wanted, it&#39;s not as flexible as the first version o=
f foo.<br>
&gt;<br>
&gt; The first version would allow pointer/reference to function, a lambda<=
br>
&gt; expression that does or does not capture lexical scope (closures), or<=
br>
&gt; normal struct with a function call operator overloaded.<br>
<br>
</div>That would be std::function.<br>
<br>
template &lt; typename Tp &gt;<br>
auto foo(std::function&lt;Tp(Tp)&gt;) -&gt; Tp;<br>
<br>
What are the deficiencies you see in std::function that would require makin=
g it<br>
a first-class type?<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote><div><br><=
/div><div>std::function is sometimes too slow (but as usual, that has to be=
 proved on a case-by-case basis, otherwise it&#39;s premature optimization)=
..</div>
<div>I guess it might be possible to express such a template constraint usi=
ng some sort of concepts.</div></div><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e014946f461a6cb04e79d4453--

.

------=_Part_424_2131086.1380564606287
Content-Type: text/plain; charset=ISO-8859-1

The problems with using library solution such as std::function is:

   - std::function uses heap allocation by default.
   - If a programmer wants to use a custom allocator to avoid using heap
   allocation the code becomes more verbose and you loose the ability to write
   a lamda expression inline.
   - Adds indirection and overhead, using lambda expressions or struct with
   function call operator is more amenable to inline optimizations. Languages
   features usually give better opportunities for compiler optimizations than
   library solutions particularly in more complicated expressions and not
   single/simple use cases.
   - Depending on the implementation, debugging debug builds with
   std::function makes the call-stack bigger thus harder to debug. For example
   in VC++2010, if you look at the call-stack of using std::function vs a
   plain template function parameter in a debug-build. The situation gets
   worse when you have more complicated expressions involving
   nesting/composition of std::functions (either directly or indirectly).
   - Potentially increases compile-times, std::function is non-trivial
   template machinery.
   - Library Solutions usually requires heuristics in tools for the
   language to understand library implementations of language features.

I see std::function as work-around more than a true solution but I'm
willing to accept something that isn't necessary full on first-class
functions.

On Monday, September 30, 2013 5:57:13 PM UTC+1, Thiago Macieira wrote:
>
> On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> > It compiles as a pointer/reference to function which is not exactly what
> I
> > meant or quite wanted, it's not as flexible as the first version of foo.
> >
> > The first version would allow pointer/reference to function, a lambda
> > expression that does or does not capture lexical scope (closures), or
> > normal struct with a function call operator overloaded.
>
> That would be std::function.
>
> template < typename Tp >
> auto foo(std::function<Tp(Tp)>) -> Tp;
>
> What are the deficiencies you see in std::function that would require
> making it
> a first-class type?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
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_424_2131086.1380564606287
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The problems with using library solution such as std::func=
tion is:<br><ul><li>std::function uses heap allocation by default.</li><li>=
If a programmer wants to use a custom allocator to avoid using heap allocat=
ion the code becomes more verbose and you loose the ability to write a lamd=
a expression inline.</li><li>Adds indirection and overhead, using lambda ex=
pressions or struct with function call operator is more amenable to inline =
optimizations. Languages features usually give better opportunities for com=
piler optimizations than library solutions particularly in more complicated=
 expressions and not single/simple use cases.<br></li><li>Depending on the =
implementation, debugging debug builds with std::function makes the call-st=
ack bigger thus harder to debug. For example in VC++2010, if you look at th=
e call-stack of using std::function vs a plain template function parameter =
in a debug-build. The situation gets worse when you have more complicated e=
xpressions involving nesting/composition of std::functions (either directly=
 or indirectly).<br></li><li>Potentially increases compile-times, std::func=
tion is non-trivial template machinery.<br></li><li>Library Solutions usual=
ly requires heuristics in tools for the language to understand library impl=
ementations of language features.<br></li></ul>I see std::function as work-=
around more than a true solution but I'm willing to accept something that i=
sn't necessary full on first-class functions.<br><br>On Monday, September 3=
0, 2013 5:57:13 PM UTC+1, Thiago Macieira wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">On segunda-feira, 30 de setembro de 2013 09:39:09, snk_ki=
d wrote:
<br>&gt; It compiles as a pointer/reference to function which is not exactl=
y what I=20
<br>&gt; meant or quite wanted, it's not as flexible as the first version o=
f foo.
<br>&gt;=20
<br>&gt; The first version would allow pointer/reference to function, a lam=
bda=20
<br>&gt; expression that does or does not capture lexical scope (closures),=
 or=20
<br>&gt; normal struct with a function call operator overloaded.
<br>
<br>That would be std::function.
<br>
<br>template &lt; typename Tp &gt;=20
<br>auto foo(std::function&lt;Tp(Tp)&gt;) -&gt; Tp;=20
<br>
<br>What are the deficiencies you see in std::function that would require m=
aking it=20
<br>a first-class type?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_424_2131086.1380564606287--

.

2013/9/30 snk_kid <korcan.hussein@googlemail.com>:
> The problems with using library solution such as std::function is:
>
> std::function uses heap allocation by default.

This is clearly an incorrect rumor. The intention is to support
small-object-optimization for small callables:

[ Note: Implementations are
encouraged to avoid the use of dynamically allocated memory for small
callable objects, for example,
where f=92s target is an object holding only a pointer or reference to
an object and a member function
pointer. =97end note ]

- Daniel

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

.

--001a11c2c8ea26d9d004e79df9f1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 30 September 2013 13:15, Daniel Kr=FCgler <daniel.kruegler@gmail.com>wro=
te:

> 2013/9/30 snk_kid <korcan.hussein@googlemail.com>:
> > The problems with using library solution such as std::function is:
> >
> > std::function uses heap allocation by default.
>
> This is clearly an incorrect rumor. The intention is to support
> small-object-optimization for small callables:
>
> [ Note: Implementations are
> encouraged to avoid the use of dynamically allocated memory for small
> callable objects, for example,
> where f=92s target is an object holding only a pointer or reference to
> an object and a member function
> pointer. =97end note ]
>

To be fair, the last time I looked at the gcc implementation, the small
object optimization only had space for a non-capturing lambda, while
boost::function had space for a lambda that captured one pointer (such as
"this").

In other words, let your library vendor know what you want and why.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

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

--001a11c2c8ea26d9d004e79df9f1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 30 September 2013 13:15, Daniel Kr=FCgler <span dir=3D"=
ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">dan=
iel.kruegler@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/9/30 snk_kid &lt;<a href=3D"mailto:korc=
an.hussein@googlemail.com">korcan.hussein@googlemail.com</a>&gt;:<br>
<div class=3D"im">&gt; The problems with using library solution such as std=
::function is:<br>
&gt;<br>
&gt; std::function uses heap allocation by default.<br>
<br>
</div>This is clearly an incorrect rumor. The intention is to support<br>
small-object-optimization for small callables:<br>
<br>
[ Note: Implementations are<br>
encouraged to avoid the use of dynamically allocated memory for small<br>
callable objects, for example,<br>
where f=92s target is an object holding only a pointer or reference to<br>
an object and a member function<br>
pointer. =97end note ]<br></blockquote><div><br></div><div>To be fair, the =
last time I looked at the gcc implementation, the small object optimization=
 only had space for a non-capturing lambda, while boost::function had space=
 for a lambda that captured one pointer (such as &quot;this&quot;).</div>

<div><br></div><div>In other words, let your library vendor know what you w=
ant and why.</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=A0 (847) 691-1404
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c8ea26d9d004e79df9f1--

.

------=_Part_305_23202138.1380565821972
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Still is a problem though, since this is not guaranteed for every=20
implementation and if you want to enforce a particular allocation strategy=
=20
with std::function code becomes verbose since you have to pass an instance=
=20
of your allocator type to one of the constructors of std::function as far=
=20
as I'm aware.

A normal template function parameter doesn't have this issue, lambda=20
expressions are stack allocated by default. If there was no difference=20
between the 2 then all of the standard library generic algorithms would or=
=20
should be using std::function otherwise why aren't they?

On Monday, September 30, 2013 7:15:39 PM UTC+1, Daniel Kr=FCgler wrote:
>
> 2013/9/30 snk_kid <korcan....@googlemail.com <javascript:>>:=20
> > The problems with using library solution such as std::function is:=20
> >=20
> > std::function uses heap allocation by default.=20
>
> This is clearly an incorrect rumor. The intention is to support=20
> small-object-optimization for small callables:=20
>
> [ Note: Implementations are=20
> encouraged to avoid the use of dynamically allocated memory for small=20
> callable objects, for example,=20
> where f=92s target is an object holding only a pointer or reference to=20
> an object and a member function=20
> pointer. =97end note ]=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_305_23202138.1380565821972
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Still is a problem though, since this is not guaranteed fo=
r every implementation and if you want to enforce a particular allocation s=
trategy with std::function code becomes verbose since you have to pass an i=
nstance of your allocator type to one of the constructors of std::function =
as far as I'm aware.<br><br>A normal template function parameter doesn't ha=
ve this issue, lambda expressions are stack allocated by default. If there =
was no difference between the 2 then all of the standard library generic al=
gorithms would or should be using std::function otherwise why aren't they?<=
br><br>On Monday, September 30, 2013 7:15:39 PM UTC+1, Daniel Kr=FCgler wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">2013/9/30 snk_kid &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"9LuHUvv-e2IJ"=
>korcan....@googlemail.com</a><wbr>&gt;:
<br>&gt; The problems with using library solution such as std::function is:
<br>&gt;
<br>&gt; std::function uses heap allocation by default.
<br>
<br>This is clearly an incorrect rumor. The intention is to support
<br>small-object-optimization for small callables:
<br>
<br>[ Note: Implementations are
<br>encouraged to avoid the use of dynamically allocated memory for small
<br>callable objects, for example,
<br>where f=92s target is an object holding only a pointer or reference to
<br>an object and a member function
<br>pointer. =97end note ]
<br>
<br>- Daniel
<br></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_305_23202138.1380565821972--

.

--001a11c3612a9f86de04e79e1495
Content-Type: text/plain; charset=ISO-8859-1

On 30 September 2013 13:10, snk_kid <korcan.hussein@googlemail.com> wrote:

> The problems with using library solution such as std::function is:
>
>    - Adds indirection and overhead, using lambda expressions or struct
>    with function call operator is more amenable to inline optimizations.
>    Languages features usually give better opportunities for compiler
>    optimizations than library solutions particularly in more complicated
>    expressions and not single/simple use cases.
>
> That doesn't have to be true for types in the standard library, since
their behavior is well specified, and a vendor could take advantage of it.


>
>    - Depending on the implementation, debugging debug builds with
>    std::function makes the call-stack bigger thus harder to debug.
>
>
I've never found "bigger call stack" as the issue with debugging.

>
>    - For example in VC++2010, if you look at the call-stack of using
>    std::function vs a plain template function parameter in a debug-build. The
>    situation gets worse when you have more complicated expressions involving
>    nesting/composition of std::functions (either directly or indirectly).
>
>
As long as you are binding the functions at run time instead of compile
time, I fail to see how a different mechanism would be any better.


>
>    - Potentially increases compile-times, std::function is non-trivial
>    template machinery.
>
>
Unless you have measurements, this is just FUD.  It isn't that complicated.


>
>    - Library Solutions usually requires heuristics in tools for the
>    language to understand library implementations of language features.
>
>
And it takes a lot longer for tools to adapt to language features.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 30 September 2013 13:10, snk_kid <span dir=3D"ltr">&lt;=
<a href=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.h=
ussein@googlemail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The problems with using lib=
rary solution such as std::function is:<br><ul><li>Adds indirection and ove=
rhead, using lambda expressions or struct with function call operator is mo=
re amenable to inline optimizations. Languages features usually give better=
 opportunities for compiler optimizations than library solutions particular=
ly in more complicated expressions and not single/simple use cases.<br>

</li></ul></div></blockquote><div>That doesn&#39;t have to be true for type=
s in the standard library, since their behavior is well specified, and a ve=
ndor could take advantage of it.</div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div dir=3D"ltr"><ul><li>Depending on the implementation, debugging debug b=
uilds with std::function makes the call-stack bigger thus harder to debug. =
</li></ul></div></blockquote><div><br></div><div>I&#39;ve never found &quot=
;bigger call stack&quot; as the issue with debugging.=A0<br>

</div><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"><ul><li>For example i=
n VC++2010, if you look at the call-stack of using std::function vs a plain=
 template function parameter in a debug-build. The situation gets worse whe=
n you have more complicated expressions involving nesting/composition of st=
d::functions (either directly or indirectly).<br>

</li></ul></div></blockquote><div><br></div><div>As long as you are binding=
 the functions at run time instead of compile time, I fail to see how a dif=
ferent mechanism would be any better.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><ul><li>Potentially increases compile-times, std::function=
 is non-trivial template machinery.<br></li></ul></div></blockquote><div><b=
r></div><div>Unless you have measurements, this is just FUD. =A0It isn&#39;=
t that complicated.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><ul><li>Libra=
ry Solutions usually requires heuristics in tools for the language to under=
stand library implementations of language features.<br>

</li></ul></div></blockquote><div><br></div><div>And it takes a lot longer =
for tools to adapt to language features.</div></div>-- <br>=A0Nevin &quot;:=
-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3612a9f86de04e79e1495--

.

------=_Part_2233_17860666.1380568499578
Content-Type: text/plain; charset=ISO-8859-1


>
>
>>    - Depending on the implementation, debugging debug builds with
>>    std::function makes the call-stack bigger thus harder to debug.
>>
>>
> I've never found "bigger call stack" as the issue with debugging.
>

I haven't had much problems personally but I've seen cases with other
people tripping up and saying "why!!!", one example was where a one person
was using std::function in function parameters a lot instead of using plain
template function parameters, another programmer was debugging code and had
a gigantic call-stack most of it all coming from implementation layers of
different invocations of std::function.

The example was roughly equivalent to nested std::for_each where the
function parameter was using std::function (unlike std::for_each). It's
definitely a head scratch when you see it, not so much in terms of
difficulty but more in terms of why it has to be this way & wtf.

Granted this was a particular implementation of std::function and doesn't
necessarily apply to all compiler vendor implementations.


>>    - For example in VC++2010, if you look at the call-stack of using
>>    std::function vs a plain template function parameter in a debug-build. The
>>    situation gets worse when you have more complicated expressions involving
>>    nesting/composition of std::functions (either directly or indirectly).
>>
>>
> As long as you are binding the functions at run time instead of compile
> time, I fail to see how a different mechanism would be any better.
>
>

My original intent is a bit more specific than asking for full on
first-class functions (all though why not? why don't we discuss the
possibility it instead of dismissing it out-right). I'm talking more about
a mechanism to to specify and self-document what the parameter and returns
type should/must be for a callable entity in a template function and maybe
the basis for future versions of C++ which adds full first-class functions.

I don't mean to say get rid of std::function outright, I'm willing to
accept it in different cases like data-members and containers but for
functions like the standard library generic algorithms where I think it's
clear they don't use std::function for performance reasons it would be nice
to have the ability to specify a function signature.


--

---
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_2233_17860666.1380568499578
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><ul><li>Depending on the implementation, debugging debug b=
uilds with std::function makes the call-stack bigger thus harder to debug. =
</li></ul></div></blockquote><div><br></div><div>I've never found "bigger c=
all stack" as the issue with debugging.&nbsp;<br></div></div></div></div></=
blockquote><div><br>I haven't had much problems personally but I've seen ca=
ses with other people tripping up and saying "why!!!", one example was wher=
e a one person was using std::function in function parameters a lot instead=
 of using plain template function parameters, another programmer was debugg=
ing code and had a gigantic call-stack most of it all coming from implement=
ation layers of different invocations of std::function.<br><br>The example =
was roughly equivalent to nested std::for_each where the function parameter=
 was using std::function (unlike std::for_each). It's definitely a head scr=
atch when you see it, not so much in terms of difficulty but more in terms =
of why it has to be this way &amp; wtf. <br><br>Granted this was a particul=
ar implementation of std::function and doesn't necessarily apply to all com=
piler vendor implementations.<br><br></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><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"><ul><li>For example i=
n VC++2010, if you look at the call-stack of using std::function vs a plain=
 template function parameter in a debug-build. The situation gets worse whe=
n you have more complicated expressions involving nesting/composition of st=
d::functions (either directly or indirectly).<br>

</li></ul></div></blockquote><div><br></div><div>As long as you are binding=
 the functions at run time instead of compile time, I fail to see how a dif=
ferent mechanism would be any better.</div><div>&nbsp;</div></div></div></d=
iv></blockquote><div><br>My original intent is a bit more specific than ask=
ing for full on first-class functions (all though why not? why don't we dis=
cuss the possibility it instead of dismissing it out-right). I'm talking mo=
re about a mechanism to to specify and self-document what the parameter and=
 returns type should/must be for a callable entity in a template function a=
nd maybe the basis for future versions of C++ which adds full first-class f=
unctions.<br><br>I don't mean to say get rid of std::function outright, I'm=
 willing to accept it in different cases like data-members and containers b=
ut for functions like the standard library generic algorithms where I think=
 it's clear they don't use std::function for performance reasons it would b=
e nice to have the ability to specify a function signature.<br><br><br></di=
v><div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2233_17860666.1380568499578--

.

--001a11c2c8ea4e084e04e79ecca4
Content-Type: text/plain; charset=ISO-8859-1

On 30 September 2013 14:14, snk_kid <korcan.hussein@googlemail.com> wrote:

>
>>>    - Depending on the implementation, debugging debug builds with
>>>    std::function makes the call-stack bigger thus harder to debug.
>>>
>>>
>> I've never found "bigger call stack" as the issue with debugging.
>>
>
> I haven't had much problems personally but I've seen cases with other
> people tripping up and saying "why!!!", one example was where a one person
> was using std::function in function parameters a lot instead of using plain
> template function parameters, another programmer was debugging code and had
> a gigantic call-stack most of it all coming from implementation layers of
> different invocations of std::function.
>

And you think a magic language feature is going to be *easier* to debug,
where in all likelihood you'll get no information about what is happening?

>
> The example was roughly equivalent to nested std::for_each where the
> function parameter was using std::function (unlike std::for_each). It's
> definitely a head scratch when you see it, not so much in terms of
> difficulty but more in terms of why it has to be this way & wtf.
>

Teach them.  That is the cost of run time binding of functions when you
want to allow anything matching a particular callable signature.


>
> Granted this was a particular implementation of std::function and doesn't
> necessarily apply to all compiler vendor implementations.
>
>
>>>    - For example in VC++2010, if you look at the call-stack of using
>>>    std::function vs a plain template function parameter in a debug-build. The
>>>    situation gets worse when you have more complicated expressions involving
>>>    nesting/composition of std::functions (either directly or indirectly).
>>>
>>>
>> As long as you are binding the functions at run time instead of compile
>> time, I fail to see how a different mechanism would be any better.
>>
>>
>
> My original intent is a bit more specific than asking for full on
> first-class functions (all though why not? why don't we discuss the
> possibility it instead of dismissing it out-right).
>

Language features have a much higher bar to overcome.  They are useful for
things that cannot be (easily) expressed in the language, but they also
have a huge cost as opposed to just adding a library (which anyone can do
in the interim).

>
> I don't mean to say get rid of std::function outright, I'm willing to
> accept it in different cases like data-members and containers but for
> functions like the standard library generic algorithms where I think it's
> clear they don't use std::function for performance reasons it would be nice
> to have the ability to specify a function signature.
>

How does that specification differ from what we can get with concepts lite?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 30 September 2013 14:14, snk_kid <span dir=3D"ltr">&lt;=
<a href=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.h=
ussein@googlemail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">

<div dir=3D"ltr"><ul><li>Depending on the implementation, debugging debug b=
uilds with std::function makes the call-stack bigger thus harder to debug. =
</li></ul></div></blockquote><div><br></div><div>I&#39;ve never found &quot=
;bigger call stack&quot; as the issue with debugging.=A0<br>

</div></div></div></div></blockquote></div><div><br>I haven&#39;t had much =
problems personally but I&#39;ve seen cases with other people tripping up a=
nd saying &quot;why!!!&quot;, one example was where a one person was using =
std::function in function parameters a lot instead of using plain template =
function parameters, another programmer was debugging code and had a gigant=
ic call-stack most of it all coming from implementation layers of different=
 invocations of std::function.<br>

</div></div></blockquote><div><br></div><div>And you think a magic language=
 feature is going to be *easier* to debug, where in all likelihood you&#39;=
ll get no information about what is happening?=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">

<div dir=3D"ltr"><div><br>The example was roughly equivalent to nested std:=
:for_each where the function parameter was using std::function (unlike std:=
:for_each). It&#39;s definitely a head scratch when you see it, not so much=
 in terms of difficulty but more in terms of why it has to be this way &amp=
; wtf. <br>

</div></div></blockquote><div><br></div><div>Teach them. =A0That is the cos=
t of run time binding of functions when you want to allow anything matching=
 a particular callable signature.</div><div>=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">

<div dir=3D"ltr"><div><br>Granted this was a particular implementation of s=
td::function and doesn&#39;t necessarily apply to all compiler vendor imple=
mentations.<br><br></div><div class=3D"im"><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>

</div><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"><ul><li>For example i=
n VC++2010, if you look at the call-stack of using std::function vs a plain=
 template function parameter in a debug-build. The situation gets worse whe=
n you have more complicated expressions involving nesting/composition of st=
d::functions (either directly or indirectly).<br>



</li></ul></div></blockquote><div><br></div><div>As long as you are binding=
 the functions at run time instead of compile time, I fail to see how a dif=
ferent mechanism would be any better.</div><div>=A0</div></div></div></div>

</blockquote></div><div><br>My original intent is a bit more specific than =
asking for full on first-class functions (all though why not? why don&#39;t=
 we discuss the possibility it instead of dismissing it out-right).</div>

</div></blockquote><div><br></div><div>Language features have a much higher=
 bar to overcome. =A0They are useful for things that cannot be (easily) exp=
ressed in the language, but they also have a huge cost as opposed to just a=
dding a library (which anyone can do in the interim).</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I don&#39;t mean t=
o say get rid of std::function outright, I&#39;m willing to accept it in di=
fferent cases like data-members and containers but for functions like the s=
tandard library generic algorithms where I think it&#39;s clear they don&#3=
9;t use std::function for performance reasons it would be nice to have the =
ability to specify a function signature.<br>

</div></div></blockquote><div><br></div><div>How does that specification di=
ffer from what we can get with concepts lite?</div></div>-- <br>=A0Nevin &q=
uot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
 target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c8ea4e084e04e79ecca4--

.

On segunda-feira, 30 de setembro de 2013 11:10:06, snk_kid wrote:
> The problems with using library solution such as std::function is:
>
>    - std::function uses heap allocation by default.

Where else would it store the information it needs? The std::function object
cannot be arbitrarily big: the user's lambda or functor can be arbitrarily
big, so it needs to use the heap.

>    - If a programmer wants to use a custom allocator to avoid using heap
>    allocation the code becomes more verbose and you loose the ability to
> write a lamda expression inline.

Also note that std::function is meant to be passed by value and it will be
copied. Adding the allocator to the parameter list would be quite a drawback
(even if it were possible at this time).

>    - Adds indirection and overhead, using lambda expressions or struct with
>    function call operator is more amenable to inline optimizations.
> Languages features usually give better opportunities for compiler
> optimizations than library solutions particularly in more complicated
> expressions and not single/simple use cases.

I don't see a way around this either. It has to be indirect, since the code
receiving a std::function does not know whether the data being carried is
pointing to a stateless function, bound member function, functor or lambda.

Still, given a good implementation and a good compiler, it should be able to
inline everything. Though, to be honest, I don't think this is an area where
compiler developers should spend too much time on: std::function is meant to
be used where a generic function is required and often in non-inline code.

>    - Depending on the implementation, debugging debug builds with
>    std::function makes the call-stack bigger thus harder to debug. For
> example in VC++2010, if you look at the call-stack of using std::function
> vs a plain template function parameter in a debug-build. The situation gets
> worse when you have more complicated expressions involving
>    nesting/composition of std::functions (either directly or indirectly).

Bad implementations should not be cause for dropping / deprecating a feature.
Only the inability to write a good implementation should be.

>    - Potentially increases compile-times, std::function is non-trivial
>    template machinery.

True.

>    - Library Solutions usually requires heuristics in tools for the
>    language to understand library implementations of language features.
>
> I see std::function as work-around more than a true solution but I'm
> willing to accept something that isn't necessary full on first-class
> functions.

What is your true solution? How would you solve some of the problems I
mentioned?

In specific, I really *no* *way* of implementing a generic bound function
pointer without the possibility of allocating memory. Language-only solutions
would require no dynamic memory allocation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

--001a11c3a8cc3b134704e79f6cb0
Content-Type: text/plain; charset=ISO-8859-1

>Still, given a good implementation and a good compiler, it should be able
to inline everything

I don't see how the compiler could inline that; the function called is not
known until run time.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Sep 30, 2013 at 1:06 PM, Thiago Macieira <thiago@macieira.org>wrote:

> On segunda-feira, 30 de setembro de 2013 11:10:06, snk_kid wrote:
> > The problems with using library solution such as std::function is:
> >
> >    - std::function uses heap allocation by default.
>
> Where else would it store the information it needs? The std::function
> object
> cannot be arbitrarily big: the user's lambda or functor can be arbitrarily
> big, so it needs to use the heap.
>
> >    - If a programmer wants to use a custom allocator to avoid using heap
> >    allocation the code becomes more verbose and you loose the ability to
> > write a lamda expression inline.
>
> Also note that std::function is meant to be passed by value and it will be
> copied. Adding the allocator to the parameter list would be quite a
> drawback
> (even if it were possible at this time).
>
> >    - Adds indirection and overhead, using lambda expressions or struct
> with
> >    function call operator is more amenable to inline optimizations.
> > Languages features usually give better opportunities for compiler
> > optimizations than library solutions particularly in more complicated
> > expressions and not single/simple use cases.
>
> I don't see a way around this either. It has to be indirect, since the code
> receiving a std::function does not know whether the data being carried is
> pointing to a stateless function, bound member function, functor or lambda.
>
> Still, given a good implementation and a good compiler, it should be able
> to
> inline everything. Though, to be honest, I don't think this is an area
> where
> compiler developers should spend too much time on: std::function is meant
> to
> be used where a generic function is required and often in non-inline code.
>
> >    - Depending on the implementation, debugging debug builds with
> >    std::function makes the call-stack bigger thus harder to debug. For
> > example in VC++2010, if you look at the call-stack of using std::function
> > vs a plain template function parameter in a debug-build. The situation
> gets
> > worse when you have more complicated expressions involving
> >    nesting/composition of std::functions (either directly or indirectly).
>
> Bad implementations should not be cause for dropping / deprecating a
> feature.
> Only the inability to write a good implementation should be.
>
> >    - Potentially increases compile-times, std::function is non-trivial
> >    template machinery.
>
> True.
>
> >    - Library Solutions usually requires heuristics in tools for the
> >    language to understand library implementations of language features.
> >
> > I see std::function as work-around more than a true solution but I'm
> > willing to accept something that isn't necessary full on first-class
> > functions.
>
> What is your true solution? How would you solve some of the problems I
> mentioned?
>
> In specific, I really *no* *way* of implementing a generic bound function
> pointer without the possibility of allocating memory. Language-only
> solutions
> would require no dynamic memory allocation.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>&gt;Still, given a good implementation and a good com=
piler, it should be able to=A0inline everything</div><div>=A0</div><div>I d=
on&#39;t see how the compiler could inline that; the function called is not=
 known until run time.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Sep 30, 2013 at 1:06 PM, Thiago =
Macieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

On segunda-feira, 30 de setembro de 2013 11:10:06, snk_kid wrote:<br>
&gt; The problems with using library solution such as std::function is:<br>
&gt;<br>
&gt; =A0 =A0- std::function uses heap allocation by default.<br>
<br>
Where else would it store the information it needs? The std::function objec=
t<br>
cannot be arbitrarily big: the user&#39;s lambda or functor can be arbitrar=
ily<br>
big, so it needs to use the heap.<br>
<br>
&gt; =A0 =A0- If a programmer wants to use a custom allocator to avoid usin=
g heap<br>
&gt; =A0 =A0allocation the code becomes more verbose and you loose the abil=
ity to<br>
&gt; write a lamda expression inline.<br>
<br>
Also note that std::function is meant to be passed by value and it will be<=
br>
copied. Adding the allocator to the parameter list would be quite a drawbac=
k<br>
(even if it were possible at this time).<br>
<br>
&gt; =A0 =A0- Adds indirection and overhead, using lambda expressions or st=
ruct with<br>
&gt; =A0 =A0function call operator is more amenable to inline optimizations=
..<br>
&gt; Languages features usually give better opportunities for compiler<br>
&gt; optimizations than library solutions particularly in more complicated<=
br>
&gt; expressions and not single/simple use cases.<br>
<br>
I don&#39;t see a way around this either. It has to be indirect, since the =
code<br>
receiving a std::function does not know whether the data being carried is<b=
r>
pointing to a stateless function, bound member function, functor or lambda.=
<br>
<br>
Still, given a good implementation and a good compiler, it should be able t=
o<br>
inline everything. Though, to be honest, I don&#39;t think this is an area =
where<br>
compiler developers should spend too much time on: std::function is meant t=
o<br>
be used where a generic function is required and often in non-inline code.<=
br>
<br>
&gt; =A0 =A0- Depending on the implementation, debugging debug builds with<=
br>
&gt; =A0 =A0std::function makes the call-stack bigger thus harder to debug.=
 For<br>
&gt; example in VC++2010, if you look at the call-stack of using std::funct=
ion<br>
&gt; vs a plain template function parameter in a debug-build. The situation=
 gets<br>
&gt; worse when you have more complicated expressions involving<br>
&gt; =A0 =A0nesting/composition of std::functions (either directly or indir=
ectly).<br>
<br>
Bad implementations should not be cause for dropping / deprecating a featur=
e.<br>
Only the inability to write a good implementation should be.<br>
<br>
&gt; =A0 =A0- Potentially increases compile-times, std::function is non-tri=
vial<br>
&gt; =A0 =A0template machinery.<br>
<br>
True.<br>
<br>
&gt; =A0 =A0- Library Solutions usually requires heuristics in tools for th=
e<br>
&gt; =A0 =A0language to understand library implementations of language feat=
ures.<br>
&gt;<br>
&gt; I see std::function as work-around more than a true solution but I&#39=
;m<br>
&gt; willing to accept something that isn&#39;t necessary full on first-cla=
ss<br>
&gt; functions.<br>
<br>
What is your true solution? How would you solve some of the problems I<br>
mentioned?<br>
<br>
In specific, I really *no* *way* of implementing a generic bound function<b=
r>
pointer without the possibility of allocating memory. Language-only solutio=
ns<br>
would require no dynamic memory allocation.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3a8cc3b134704e79f6cb0--

.

On segunda-feira, 30 de setembro de 2013 13:09:28, Billy O'Neal wrote:
> I don't see how the compiler could inline that; the function called is not
> known until run time.

void f();
void g(std::function<void(void)> x) { x(); }
void h()
{
    g(f);
}

A sufficiently-advanced compiler and library implementation could detect that
the code above simply calls f and could inline everything.

But, like I said, this is not the typical, expected use of std::function. An
inline function like g above is best written with a template, maybe with some
concepts to constrain it.

The typical case is like you said: the called function is not known until
runtime.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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_610_1235949.1380572751574
Content-Type: text/plain; charset=ISO-8859-1


>
>
> And you think a magic language feature is going to be *easier* to debug,
> where in all likelihood you'll get no information about what is happening?
>

Why are being so aggressive & condescending? anyways my point is the person
who used std::function in parameters, if he used normal template function
parameters instead. That particular case of the other guy debugging, the
only thing you would see is just lambda calls in the call-stack not layers
and layers of implementation details of std::function. The reason why the
first guy used std::function in the first-place is because he wanted to
constrain & self-document what the parameter and return types are of the
function parameter is.

Soooo if we had a way to either specify the types of callable-entities or
constrain parameter types to particular function signatures then we don't
need to use std::function for this particular use-case besides
debuggability wasn't the only reason I mentioned.

Language features have a much higher bar to overcome.  They are useful for
> things that cannot be (easily) expressed in the language, but they also
> have a huge cost as opposed to just adding a library (which anyone can do
> in the interim).
>

I don't think this needs to be said it's pretty obvious to anyone but we
have our "interim", that was the point of this thread is discuss the
potential future. I don't expect this to be easy, quick and needs to be
done immediately.


> How does that specification differ from what we can get with concepts lite?
>

It doesn't, there's no specification or one only way I'm just describing
how it might ideally look like. Is it even possible to describe such a
template constraint (to full genericity)? even if it was possible I don't
think it would be good and I don't think it would scale well once you start
using multiple function parameters and and other types constraints, it will
get quite verbose I think.

If you had some kind of first-class function types (like re-purposing
function signatures) this would not be an opposing feature from concepts,
they would be quite orthogonal.

--

---
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_610_1235949.1380572751574
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div><br></div><div>And you think a mag=
ic language feature is going to be *easier* to debug, where in all likeliho=
od you'll get no information about what is happening?&nbsp;</div></div></di=
v></div></blockquote><div class=3D"gmail_quote"><br>Why are being so aggres=
sive &amp; condescending? anyways my point is the person who used std::func=
tion in parameters, if he used normal template function parameters instead.=
 That particular case of the other guy debugging, the only thing you would =
see is just lambda calls in the call-stack not layers and layers of impleme=
ntation details of std::function. The reason why the first guy used std::fu=
nction in the first-place is because he wanted to constrain &amp; self-docu=
ment what the parameter and return types are of the function parameter is.<=
br><br>Soooo if we had a way to either specify the types of callable-entiti=
es or constrain parameter types to particular function signatures then we d=
on't need to use std::function for this particular use-case besides debugga=
bility wasn't the only reason I mentioned.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
"><div>Language features have a much higher bar to overcome. &nbsp;They are=
 useful for things that cannot be (easily) expressed in the language, but t=
hey also have a huge cost as opposed to just adding a library (which anyone=
 can do in the interim).</div></div></div></div></blockquote><div class=3D"=
gmail_quote">&nbsp;<br>I don't think this needs to be said it's pretty obvi=
ous to anyone but we have our "interim", that was the point of this thread =
is discuss the potential future. I don't expect this to be easy, quick and =
needs to be done immediately.<br></div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">

<div>How does that specification differ from what we can get with concepts =
lite?</div></div></div></div></blockquote><div><br>It doesn't, there's no s=
pecification or one only way I'm just describing how it might ideally look =
like. Is it even possible to describe such a template constraint (to full g=
enericity)? even if it was possible I don't think it would be good and I do=
n't think it would scale well once you start using multiple function parame=
ters and and other types constraints, it will get quite verbose I think.<br=
><br>If you had some kind of first-class function types (like re-purposing =
function signatures) this would not be an opposing feature from concepts, t=
hey would be quite orthogonal.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_610_1235949.1380572751574--

.

------=_Part_327_24753645.1380574631152
Content-Type: text/plain; charset=ISO-8859-1

I'm talking more about higher-order functions like generic algorithms
specifically than the general case of storing function values but we can
discuss that too. I don't know if you have looked into the Rust programming
language before but they have different types of first-class functions
depending on how they be will be allocated & owner-ship semantics.

I guess it would be very similar to how we have capture clauses for lambda
expressions today in C++ where we can explicitly specify what & how we
capture lexical scope. So in the case of function-types we can explicitly
specifying how the closures should be allocated and maybe the owner-ship
semantics (kind of like std::unique_ptr, std::shared_ptr, etc).

On Monday, September 30, 2013 9:06:58 PM UTC+1, Thiago Macieira wrote:
>
> On segunda-feira, 30 de setembro de 2013 11:10:06, snk_kid wrote:
> > The problems with using library solution such as std::function is:
> >
> >    - std::function uses heap allocation by default.
>
> Where else would it store the information it needs? The std::function
> object
> cannot be arbitrarily big: the user's lambda or functor can be arbitrarily
> big, so it needs to use the heap.
>
> >    - If a programmer wants to use a custom allocator to avoid using heap
> >    allocation the code becomes more verbose and you loose the ability to
> > write a lamda expression inline.
>
> Also note that std::function is meant to be passed by value and it will be
> copied. Adding the allocator to the parameter list would be quite a
> drawback
> (even if it were possible at this time).
>
> >    - Adds indirection and overhead, using lambda expressions or struct
> with
> >    function call operator is more amenable to inline optimizations.
> > Languages features usually give better opportunities for compiler
> > optimizations than library solutions particularly in more complicated
> > expressions and not single/simple use cases.
>
> I don't see a way around this either. It has to be indirect, since the
> code
> receiving a std::function does not know whether the data being carried is
> pointing to a stateless function, bound member function, functor or
> lambda.
>
> Still, given a good implementation and a good compiler, it should be able
> to
> inline everything. Though, to be honest, I don't think this is an area
> where
> compiler developers should spend too much time on: std::function is meant
> to
> be used where a generic function is required and often in non-inline code.
>
> >    - Depending on the implementation, debugging debug builds with
> >    std::function makes the call-stack bigger thus harder to debug. For
> > example in VC++2010, if you look at the call-stack of using
> std::function
> > vs a plain template function parameter in a debug-build. The situation
> gets
> > worse when you have more complicated expressions involving
> >    nesting/composition of std::functions (either directly or
> indirectly).
>
> Bad implementations should not be cause for dropping / deprecating a
> feature.
> Only the inability to write a good implementation should be.
>
> >    - Potentially increases compile-times, std::function is non-trivial
> >    template machinery.
>
> True.
>
> >    - Library Solutions usually requires heuristics in tools for the
> >    language to understand library implementations of language features.
> >
> > I see std::function as work-around more than a true solution but I'm
> > willing to accept something that isn't necessary full on first-class
> > functions.
>
> What is your true solution? How would you solve some of the problems I
> mentioned?
>
> In specific, I really *no* *way* of implementing a generic bound function
> pointer without the possibility of allocating memory. Language-only
> solutions
> would require no dynamic memory allocation.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
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_327_24753645.1380574631152
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I'm talking more about higher-order functions like generic=
 algorithms specifically than the general case of storing function values b=
ut we can discuss that too. I don't know if you have looked into the Rust p=
rogramming language before but they have different types of first-class fun=
ctions depending on how they be will be allocated &amp; owner-ship semantic=
s.<br><br>I guess it would be very similar to how we have capture clauses f=
or lambda expressions today in C++ where we can explicitly specify what &am=
p; how we capture lexical scope. So in the case of function-types we can ex=
plicitly specifying how the closures should be allocated and maybe the owne=
r-ship semantics (kind of like std::unique_ptr, std::shared_ptr, etc).<br><=
br>On Monday, September 30, 2013 9:06:58 PM UTC+1, Thiago Macieira wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On segunda-feira, 30 de setembro=
 de 2013 11:10:06, snk_kid wrote:
<br>&gt; The problems with using library solution such as std::function is:
<br>&gt;=20
<br>&gt; &nbsp; &nbsp;- std::function uses heap allocation by default.
<br>
<br>Where else would it store the information it needs? The std::function o=
bject=20
<br>cannot be arbitrarily big: the user's lambda or functor can be arbitrar=
ily=20
<br>big, so it needs to use the heap.
<br>
<br>&gt; &nbsp; &nbsp;- If a programmer wants to use a custom allocator to =
avoid using heap
<br>&gt; &nbsp; &nbsp;allocation the code becomes more verbose and you loos=
e the ability to
<br>&gt; write a lamda expression inline.
<br>
<br>Also note that std::function is meant to be passed by value and it will=
 be=20
<br>copied. Adding the allocator to the parameter list would be quite a dra=
wback=20
<br>(even if it were possible at this time).
<br>
<br>&gt; &nbsp; &nbsp;- Adds indirection and overhead, using lambda express=
ions or struct with
<br>&gt; &nbsp; &nbsp;function call operator is more amenable to inline opt=
imizations.
<br>&gt; Languages features usually give better opportunities for compiler
<br>&gt; optimizations than library solutions particularly in more complica=
ted
<br>&gt; expressions and not single/simple use cases.
<br>
<br>I don't see a way around this either. It has to be indirect, since the =
code=20
<br>receiving a std::function does not know whether the data being carried =
is=20
<br>pointing to a stateless function, bound member function, functor or lam=
bda.
<br>
<br>Still, given a good implementation and a good compiler, it should be ab=
le to=20
<br>inline everything. Though, to be honest, I don't think this is an area =
where=20
<br>compiler developers should spend too much time on: std::function is mea=
nt to=20
<br>be used where a generic function is required and often in non-inline co=
de.
<br>
<br>&gt; &nbsp; &nbsp;- Depending on the implementation, debugging debug bu=
ilds with
<br>&gt; &nbsp; &nbsp;std::function makes the call-stack bigger thus harder=
 to debug. For
<br>&gt; example in VC++2010, if you look at the call-stack of using std::f=
unction
<br>&gt; vs a plain template function parameter in a debug-build. The situa=
tion gets
<br>&gt; worse when you have more complicated expressions involving
<br>&gt; &nbsp; &nbsp;nesting/composition of std::functions (either directl=
y or indirectly).
<br>
<br>Bad implementations should not be cause for dropping / deprecating a fe=
ature.=20
<br>Only the inability to write a good implementation should be.
<br>
<br>&gt; &nbsp; &nbsp;- Potentially increases compile-times, std::function =
is non-trivial
<br>&gt; &nbsp; &nbsp;template machinery.
<br>
<br>True.
<br>
<br>&gt; &nbsp; &nbsp;- Library Solutions usually requires heuristics in to=
ols for the
<br>&gt; &nbsp; &nbsp;language to understand library implementations of lan=
guage features.
<br>&gt;=20
<br>&gt; I see std::function as work-around more than a true solution but I=
'm
<br>&gt; willing to accept something that isn't necessary full on first-cla=
ss
<br>&gt; functions.
<br>
<br>What is your true solution? How would you solve some of the problems I=
=20
<br>mentioned?
<br>
<br>In specific, I really *no* *way* of implementing a generic bound functi=
on=20
<br>pointer without the possibility of allocating memory. Language-only sol=
utions=20
<br>would require no dynamic memory allocation.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_327_24753645.1380574631152--

.

--001a11c2ddb81dda9104e7a02b8a
Content-Type: text/plain; charset=ISO-8859-1

On 30 September 2013 15:25, snk_kid <korcan.hussein@googlemail.com> wrote:

>
>> And you think a magic language feature is going to be *easier* to debug,
>> where in all likelihood you'll get no information about what is happening?
>>
>
> Why are being so aggressive & condescending?
>

I thought your idea was about making things easier for run time binding
than std::function is.  I, like others here, have no idea how such a thing
would work.

And if it isn't about run time binding, then why do you keep bringing up
std::function?


>  anyways my point is the person who used std::function in parameters, if
> he used normal template function parameters instead.
>

Why would someone do that?  If you care about performance, you stay in
template-land; if not, I don't see any way around what std::function does,
unless you limit yourself to C function pointers (which you can still do
now).


> That particular case of the other guy debugging, the only thing you would
> see is just lambda calls in the call-stack not layers and layers of
> implementation details of std::function. The reason why the first guy used
> std::function in the first-place is because he wanted to constrain &
> self-document what the parameter and return types are of the function
> parameter is.
>

The template engine will usually constrain this, albeit with horrible error
messages when misused.  Concepts are constraints on templates, and will do
much better.

But you really have to decide whether you need compile time binding or run
time binding.  We cannot help it if people abuse the run time binding
mechanism when they don't need it, and I don't see any way to implement
what you are asking for at compile time that isn't the equivalent (in terms
of work the compiler has to do) of concepts.

But I could be wrong.  Please enlighten me, preferably with concrete code
examples instead of vague abstract notions.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 30 September 2013 15:25, snk_kid <span dir=3D"ltr">&lt;=
<a href=3D"mailto:korcan.hussein@googlemail.com" target=3D"_blank">korcan.h=
ussein@googlemail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>And yo=
u think a magic language feature is going to be *easier* to debug, where in=
 all likelihood you&#39;ll get no information about what is happening?=A0</=
div>

</div></div></div></blockquote></div><div class=3D"gmail_quote"><br>Why are=
 being so aggressive &amp; condescending?</div></div></blockquote><div><br>=
</div><div>I thought your idea was about making things easier for run time =
binding than std::function is. =A0I, like others here, have no idea how suc=
h a thing would work.</div>

<div><br></div><div>And if it isn&#39;t about run time binding, then why do=
 you keep bringing up std::function?</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_quote"> anyways my point is the person=
 who used std::function in parameters, if he used normal template function =
parameters instead.</div></div></blockquote><div><br></div><div>Why would s=
omeone do that? =A0If you care about performance, you stay in template-land=
; if not, I don&#39;t see any way around what std::function does, unless yo=
u limit yourself to C function pointers (which you can still do now).</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_quote"> That particular case of the other guy debugging, the only th=
ing you would see is just lambda calls in the call-stack not layers and lay=
ers of implementation details of std::function. The reason why the first gu=
y used std::function in the first-place is because he wanted to constrain &=
amp; self-document what the parameter and return types are of the function =
parameter is.<br>

</div></div></blockquote><div><br></div><div>The template engine will usual=
ly constrain this, albeit with horrible error messages when misused. =A0Con=
cepts are constraints on templates, and will do much better.</div><div><br>

</div><div>But you really have to decide whether you need compile time bind=
ing or run time binding. =A0We cannot help it if people abuse the run time =
binding mechanism when they don&#39;t need it, and I don&#39;t see any way =
to implement what you are asking for at compile time that isn&#39;t the equ=
ivalent (in terms of work the compiler has to do) of concepts.</div>

<div><br></div><div>But I could be wrong. =A0Please enlighten me, preferabl=
y with concrete code examples instead of vague abstract notions.</div></div=
>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (84=
7) 691-1404
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2ddb81dda9104e7a02b8a--

.

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

Le 30/09/13 17:54, snk_kid a =E9crit :
>
>
> I'd like to have some kind of true first-class function types or some=20
> mechanism of declaring type constraints which specify & document to=20
> other programmers what is expected of a callable entity parameter of=20
> template function, when you have code like this:
>
> |
> template<typenameFunction,typenameTp>
> autofoo(Functionfn)->Tp;
> |
>
> It's impossible to know what the expected parameter and return types=20
> must be without looking at the definition of the function or trying to=20
> figure them out from compile-errors, if you're lucky the author may=20
> have properly documented what the types are but that's usually not the=20
> case especially for projects that are still in flux.
>
> Even with documentation this still isn't as good as having this as=20
> part of the type system and having self-documenting code. I wish I=20
> could write C++ code something like this:
>
> |
> template<typenameTp>
> autofoo(Tpfn(Tp))->Tp;
> |
>
> We have function signatures in C++, can we not make into them=20
> first-class function types to some extent? If not maybe some mechisim=20
> to achieve simlliar results using template constraints while still=20
> being readable, self-documenting and able to produce comprehensible=20
> error messages when a programmer makes a mistake.
Hi,

first-class functions could be used to declare function type=20
constraints, but they do much more. first-class functions could be=20
returned by functions, be assigned, and of course called. This is what=20
std::function does as a library class.

If you want just to constraint a function, concepts should allow you to=20
write something like

|
template<typename Tp, Callable(Tp(Tp)) F>
autofoo(F f)->Tp;
|

Is this what you are looking for?

Vicente

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

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 30/09/13 17:54, snk_kid a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite="mid:bcc1925c-a0d9-453a-b9b1-db9b702486bc@isocpp.org"
      type="cite">
      <div dir="ltr"><br>
        <br>
        I'd like to have some kind of true first-class function types or
        some mechanism of declaring type constraints which specify &amp;
        document to other programmers what is expected of a callable
        entity parameter of template function, when you have code like
        this:<br>
        <br>
        <div class="prettyprint" style="background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class="prettyprint">
            <div class="subprettyprint"><span style="color: #008;"
                class="styled-by-prettify">template</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">&lt;</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #008;" class="styled-by-prettify">typename</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #606;" class="styled-by-prettify">Function</span><span
                style="color: #660;" class="styled-by-prettify">,</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #008;" class="styled-by-prettify">typename</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">&gt;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span><span style="color: #008;"
                class="styled-by-prettify">auto</span><span
                style="color: #000;" class="styled-by-prettify"> foo</span><span
                style="color: #660;" class="styled-by-prettify">(</span><span
                style="color: #606;" class="styled-by-prettify">Function</span><span
                style="color: #000;" class="styled-by-prettify"> fn</span><span
                style="color: #660;" class="styled-by-prettify">)</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">-&gt;</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #660;" class="styled-by-prettify">;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span></div>
          </code></div>
        <br>
        It's impossible to know what the expected parameter and return
        types must be without looking at the definition of the function
        or trying to figure them out from compile-errors, if you're
        lucky the author may have properly documented what the types are
        but that's usually not the case especially for projects that are
        still in flux.<br>
        <br>
        Even with documentation this still isn't as good as having this
        as part of the type system and having self-documenting code. I
        wish I could write C++ code something like this:<br>
        <br>
        <div class="prettyprint" style="background-color: rgb(250, 250,
          250); border-color: rgb(187, 187, 187); border-style: solid;
          border-width: 1px; word-wrap: break-word;"><code
            class="prettyprint">
            <div class="subprettyprint"><span style="color: #008;"
                class="styled-by-prettify">template</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">&lt;</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #008;" class="styled-by-prettify">typename</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">&gt;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span><span style="color: #008;"
                class="styled-by-prettify">auto</span><span
                style="color: #000;" class="styled-by-prettify"> foo</span><span
                style="color: #660;" class="styled-by-prettify">(</span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #000;" class="styled-by-prettify"> fn</span><span
                style="color: #660;" class="styled-by-prettify">(</span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #660;" class="styled-by-prettify">))</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #660;" class="styled-by-prettify">-&gt;</span><span
                style="color: #000;" class="styled-by-prettify"> </span><span
                style="color: #606;" class="styled-by-prettify">Tp</span><span
                style="color: #660;" class="styled-by-prettify">;</span><span
                style="color: #000;" class="styled-by-prettify"><br>
              </span></div>
          </code></div>
        <br>
        We have function signatures in C++, can we not make into them
        first-class function types to some extent? If not maybe some
        mechisim to achieve simlliar results using template constraints
        while still being readable, self-documenting and able to produce
        comprehensible error messages when a programmer makes a mistake.<br>
      </div>
    </blockquote>
    Hi,<br>
    <br>
    first-class functions could be used to declare function type
    constraints, but they do much more. first-class functions could be
    returned by functions, be assigned, and of course called. This is
    what std::function does as a library class.<br>
    <br>
    If you want just to constraint a function, concepts should allow you
    to write something like<br>
    <br>
    <div class="prettyprint" style="background-color: rgb(250, 250,
      250); border-color: rgb(187, 187, 187); border-style: solid;
      border-width: 1px; word-wrap: break-word;"><code
        class="prettyprint">
        <div class="subprettyprint"><span style="color: #008;"
            class="styled-by-prettify">template</span><span
            style="color: #000;" class="styled-by-prettify"> </span><span
            style="color: #660;" class="styled-by-prettify">&lt;</span><span
            style="color: #000;" class="styled-by-prettify"> typename
            Tp, Callable(</span><span style="color: #000;"
            class="styled-by-prettify"></span><span style="color: #606;"
            class="styled-by-prettify">Tp(Tp)) F</span><span
            style="color: #000;" class="styled-by-prettify"> </span><span
            style="color: #660;" class="styled-by-prettify">&gt;</span><span
            style="color: #000;" class="styled-by-prettify"><br>
          </span><span style="color: #008;" class="styled-by-prettify">auto</span><span
            style="color: #000;" class="styled-by-prettify"> foo</span><span
            style="color: #660;" class="styled-by-prettify">(F f</span><span
            style="color: #660;" class="styled-by-prettify">)</span><span
            style="color: #000;" class="styled-by-prettify"> </span><span
            style="color: #660;" class="styled-by-prettify">-&gt;</span><span
            style="color: #000;" class="styled-by-prettify"> </span><span
            style="color: #606;" class="styled-by-prettify">Tp</span><span
            style="color: #660;" class="styled-by-prettify">;</span><span
            style="color: #000;" class="styled-by-prettify"><br>
          </span></div>
      </code></div>
    <br>
    Is this what you are looking for?<br>
    <br>
    Vicente<br>
  </body>
</html>

<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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------000101040808020704070504--

.

------=_Part_2321_27576106.1380577749410
Content-Type: text/plain; charset=ISO-8859-1



> I thought your idea was about making things easier for run time binding
> than std::function is.  I, like others here, have no idea how such a thing
> would work.
>
> And if it isn't about run time binding, then why do you keep bringing up
> std::function?
>

I never even used the words run-time and/or binding, originally I was
responding to Thiago who mentioned using std::function instead of plain
function template parameters.

--

---
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_2321_27576106.1380577749410
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&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>I thought your =
idea was about making things easier for run time binding than std::function=
 is. &nbsp;I, like others here, have no idea how such a thing would work.</=
div>

<div><br></div><div>And if it isn't about run time binding, then why do you=
 keep bringing up std::function?</div></div></div></div></blockquote><div><=
br>I never even used the words run-time and/or binding, originally  I was r=
esponding to Thiago who mentioned using std::function instead of plain func=
tion template parameters.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2321_27576106.1380577749410--

.

------=_Part_476_7524550.1380578992774
Content-Type: text/plain; charset=ISO-8859-1


>
> first-class functions could be used to declare function type constraints,
> but they do much more. first-class functions could be returned by
> functions, be assigned, and of course called. This is what std::function
> does as a library class.
>
> If you want just to constraint a function, concepts should allow you to
> write something like
>
>  template < typename Tp, Callable(Tp(Tp)) F >
> auto foo(F f) -> Tp;
>
> Is this what you are looking for?
>

Yes this kinda of what I meant, although would type deducation rules still
work here since you don't actually use 'Tp' in the parameters of 'foo'.

I'm not quite fond of this solution as it seems like wouldn't scale well to
multiple function parameters I mean it would get quite verbose when you
have more parameters and other constraints (even constraints for the
template parameters used in "Callable").

It would seem nice if we could get something closer to looking like
first-class function types which for now aren't really first-class
functions but could be the basis and starting point for future versions of
C++. We already have a syntax for function signatures.

--

---
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_476_7524550.1380578992774
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
    first-class functions could be used to declare function type
    constraints, but they do much more. first-class functions could be
    returned by functions, be assigned, and of course called. This is
    what std::function does as a library class.<br>
    <br>
    If you want just to constraint a function, concepts should allow you
    to write something like<br>
    <br>
    <div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code>
        <div><span style=3D"color:#008">template</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"color:#=
000"> typename
            Tp, Callable(</span><span style=3D"color:#000"></span><span sty=
le=3D"color:#606">Tp(Tp)) F</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>
          </span><span style=3D"color:#008">auto</span><span style=3D"color=
:#000"> foo</span><span style=3D"color:#660">(F f</span><span style=3D"colo=
r:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">-&gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#606=
">Tp</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>
          </span></div>
      </code></div>
    <br>
    Is this what you are looking for?<br></div></blockquote><div>&nbsp;<br>=
Yes this kinda of what I meant, although would type deducation rules still =
work here since you don't actually use 'Tp' in the parameters of 'foo'.<br>=
<br>I'm not quite fond of this solution as it seems like wouldn't scale wel=
l to multiple function parameters I mean it would get quite verbose when yo=
u have more parameters and other constraints (even constraints for the temp=
late parameters used in "Callable").<br><br>It would seem nice if we could =
get something closer to looking like first-class function types which for n=
ow aren't really first-class functions but could be the basis and starting =
point for future versions of C++. We already have a syntax for function sig=
natures.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_476_7524550.1380578992774--

.

On segunda-feira, 30 de setembro de 2013 15:09:52, snk_kid wrote:
> It would seem nice if we could get something closer to looking like
> first-class function types which for now aren't really first-class
> functions but could be the basis and starting point for future versions of
> C++. We already have a syntax for function signatures.

Functions are first-class types.

That's not what you're talking about. You're talking about a generic
"callable", which is nothing more than "we can slap parentheses at the end".

Functors are not functions and you can think of all lambdas except stateless
ones as functors. There's no way a first-class type can match an arbitrary user
type like that.

It sounds to me like all you want is a good concept.

template <typename T>
concept bool MyConcept(T t)
{
    requires { t(); }
}

then you can write:
template <typename T> requires MyConcept(T)
void foo(T);

Or simplified first-level:
template <MyConcept T> void foo(T);

Or simplified second-level:
void foo(MyConcept);

With this second type of simplification, we have a template constrained to a
concept behaving much like your examples so far. And the concept can be made
arbitrarily more complex, as needed.

Now, I urge you to take a look at the concepts-lite proposal and see if it
matches your needs. I think it does.

If it doesn't, then make a proposal of what you'd like this new first-class
type to be, to do; where it could be used and where it couldn't. Please
include also how the compiler would materialise it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

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

.

----_com.android.email_294154290942340
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That is sorta broken. There is no way to call that function without one of =
1) explicit template argument or 2) creating a std::function object beforeh=
and.


Martinho

-------- Original message --------
From: Thiago Macieira <thiago@macieira.org>=20
Date: =20
To: std-proposals@isocpp.org=20
Subject: Re: [std-proposals] [C++17][wish-list] first-class function types =
or
  function-type constraints=20
=20
On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> It compiles as a pointer/reference to function which is not exactly what =
I=20
> meant or quite wanted, it's not as flexible as the first version of foo.
>=20
> The first version would allow pointer/reference to function, a lambda=20
> expression that does or does not capture lexical scope (closures), or=20
> normal struct with a function call operator overloaded.

That would be std::function.

template < typename Tp >=20
auto foo(std::function<Tp(Tp)>) -> Tp;=20

What are the deficiencies you see in std::function that would require makin=
g it=20
a first-class type?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=A0=A0 Software Architect - Intel Open Source Technology Center
=A0=A0=A0=A0=A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0=A0=A0=A0=A0 E067 918B B660 DBD1 105C=A0 966C 33F5 F005 6EF4 5358

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

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

----_com.android.email_294154290942340
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8"></head><body ><div>That is sorta broken. There is no way to call =
that function without one of 1) explicit template argument or 2) creating a=
 std::function object beforehand.</div><div><br></div><div><br></div>Martin=
ho <br><br><br>-------- Original message --------<br>From: Thiago Macieira =
&lt;thiago@macieira.org&gt; <br>Date:  <br>To: std-proposals@isocpp.org <br=
>Subject: Re: [std-proposals] [C++17][wish-list] first-class function types=
 or
  function-type constraints <br> <br><br>On segunda-feira, 30 de setembro d=
e 2013 09:39:09, snk_kid wrote:<br>&gt; It compiles as a pointer/reference =
to function which is not exactly what I <br>&gt; meant or quite wanted, it'=
s not as flexible as the first version of foo.<br>&gt; <br>&gt; The first v=
ersion would allow pointer/reference to function, a lambda <br>&gt; express=
ion that does or does not capture lexical scope (closures), or <br>&gt; nor=
mal struct with a function call operator overloaded.<br><br>That would be s=
td::function.<br><br>template &lt; typename Tp &gt; <br>auto foo(std::funct=
ion&lt;Tp(Tp)&gt;) -&gt; Tp; <br><br>What are the deficiencies you see in s=
td::function that would require making it <br>a first-class type?<br><br>--=
 <br>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org<br>&=
nbsp;&nbsp; Software Architect - Intel Open Source Technology Center<br>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; PGP/GPG: 0x6EF45358; fingerprint:<br>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; E067 918B B660 DBD1 105C&nbsp; 966C 33F5 F005 6EF4 535=
8<br><br>-- <br><br>--- <br>You received this message because you are subsc=
ribed to the Google Groups "ISO C++ Standard - Future Proposals" 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, sen=
d email to std-proposals@isocpp.org.<br>Visit this group at http://groups.g=
oogle.com/a/isocpp.org/group/std-proposals/.<br></body>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

----_com.android.email_294154290942340--



.

------=_Part_3912_25177486.1380624326268
Content-Type: text/plain; charset=ISO-8859-1



> Functions are first-class types.
>

> That's not what you're talking about. You're talking about a generic
> "callable", which is nothing more than "we can slap parentheses at the
> end".
>

C/C++ functions are not first-class entities currently but I'm not here to
argue if they are or are not now, I'm trying to start a civil, professional
discussion of potentially improving and evolving the language in the
future. I don't understand why people are starting to get hostile and
condescending.

Functors are not functions and you can think of all lambdas except
> stateless
> ones as functors.


I know what functional objects are and I know how C++ lambda expressions
are supposed to be logically equivalent too generated local structs with
functional operator overloaded (that does not mean that a compiler has to
actually generated code like that).


>
> It sounds to me like all you want is a good concept.
>
> template <typename T>
> concept bool MyConcept(T t)
> {
>     requires { t(); }
> }
>
> then you can write:
> template <typename T> requires MyConcept(T)
> void foo(T);
>
> Or simplified first-level:
> template <MyConcept T> void foo(T);
>
> Or simplified second-level:
> void foo(MyConcept);
>
> With this second type of simplification, we have a template constrained to
> a
> concept behaving much like your examples so far. And the concept can be
> made
> arbitrarily more complex, as needed.
>

I've already gone over this with Vicente J in the very post you quoted me
on but you seem to ignore it completely! Also your version lacks the
self-documenting code aspect that Vicente J's version does have since in
your example I have to go to the definition of your concept to figure what
the required parameter & return types are.

As I've asked Vicente J, I'll say the same to you. Your example may work
for simple callable-entities which do not take parameters and have a void
return type but as soon as you deal with more complicated callable entities
in particular ones which are polymophic this may not work well with
automatic type-deduction rules. An example such as Vicente J's:

template < typename Tp, Callable(Tp(Tp)) F >
auto foo(F f) -> Tp;

In this example does this still work with the type deduction rules so
programmers do not have explicity instantiate the first template parameter
and say what the type of 'Tp' is? none has responded to this question yet.

Now, I urge you to take a look at the concepts-lite proposal and see if it
> matches your needs. I think it does.
>

I'm quite aware of the concept lite proposal. I've even suggested at the
very beginning that if some kind of first-class function types aren't
feasible then if there was a way to make this work to full genericity with
template constraints (and I mean concept lite) then so be it and a concept
like this should be incorporated into the standard library as soon as
concepts are standardized.

--

---
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_3912_25177486.1380624326268
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Functions are first-class types.
<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>That's not what you're talking about. You're talking about a generic=20
<br>"callable", which is nothing more than "we can slap parentheses at the =
end".
<br></blockquote><div><br>C/C++ functions are not first-class entities curr=
ently but I'm not here=20
to argue if they are or are not now, I'm trying to start a civil,=20
professional discussion of potentially improving and evolving the=20
language in the future. I don't understand why people are starting to get=
=20
hostile and condescending.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">Functors are not functions and you can think of all lambdas excep=
t stateless=20
<br>ones as functors. </blockquote><div><br>I know what functional objects =
are and I know how C++ lambda expressions are supposed to be logically equi=
valent too generated local structs with functional operator overloaded (tha=
t does not mean that a compiler has to actually generated code like that).<=
br><div></div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>It sounds to me like all you want is a good concept.
<br>
<br>template &lt;typename T&gt;
<br>concept bool MyConcept(T t)
<br>{
<br>&nbsp; &nbsp; requires { t(); }
<br>}
<br>
<br>then you can write:
<br>template &lt;typename T&gt; requires MyConcept(T)
<br>void foo(T);
<br>
<br>Or simplified first-level:
<br>template &lt;MyConcept T&gt; void foo(T);
<br>
<br>Or simplified second-level:
<br>void foo(MyConcept);
<br>
<br>With this second type of simplification, we have a template constrained=
 to a=20
<br>concept behaving much like your examples so far. And the concept can be=
 made=20
<br>arbitrarily more complex, as needed.
<br></blockquote><div><br>I've already gone over this with Vicente J in the=
 very post you quoted me on but you seem to ignore it completely! Also your=
 version lacks the self-documenting code aspect that Vicente J's version do=
es have since in your example I have to go to the definition of your concep=
t to figure what the required parameter &amp; return types are.<br><br>As I=
've asked Vicente J, I'll say the same to you. Your example may work for si=
mple callable-entities which do not take parameters and have a void return =
type but as soon as you deal with more complicated callable entities in par=
ticular ones which are polymophic this may not work well with automatic typ=
e-deduction rules. An example such as Vicente J's:<br><br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code>
        <div><span style=3D"color:#008">template</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">&lt;</span><span style=3D"color:#=
000"> typename
            Tp, Callable(</span><span style=3D"color:#000"></span><span sty=
le=3D"color:#606">Tp(Tp)) F</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>
          </span><span style=3D"color:#008">auto</span><span style=3D"color=
:#000"> foo</span><span style=3D"color:#660">(F f</span><span style=3D"colo=
r:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">-&gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#606=
">Tp</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r>
          </span></div>
      </code></div><br>In this example does this still work with the type d=
eduction rules so programmers do not have explicity instantiate the first t=
emplate parameter and say what the type of 'Tp' is? none has responded to t=
his question yet. <br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">Now, I urge you to take a look at the concepts-lite proposal and see if i=
t=20
<br>matches your needs. I think it does.
<br></blockquote><div><br>I'm quite aware of the concept lite proposal. I'v=
e even suggested at the very beginning that if some kind of first-class fun=
ction types aren't feasible then if there was a way to make this work to fu=
ll genericity with template constraints (and I mean concept lite) then so b=
e it and a concept like this should be incorporated into the standard libra=
ry as soon as concepts are standardized.<br><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3912_25177486.1380624326268--

.

------=_Part_152_23938223.1380625139653
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure who you are responding too but I'm guessing it's me, I did not
said anything about not using plain template parameter, on the contrary I'd
like to be able to "constrain" the template parameter and self-document
what the parameter & return types are in the case of function templates
ones like generic algorithms.

However I don't feel this is the most ideal solution for the future
evolution of C++, it seems more of workaround stop gap solution. IMuy line
of thought is that since we already have function signatures maybe a better
solution is too start from here with maybe a basis to evolve C++ with real
first-class functions in the future.

On Tuesday, October 1, 2013 10:22:34 AM UTC+1, R. Martinho Fernandes wrote:
>
> That is sorta broken. There is no way to call that function without one of
> 1) explicit template argument or 2) creating a std::function object
> beforehand.
>
>
> Martinho
>
>
> -------- Original message --------
> From: Thiago Macieira <thi...@macieira.org <javascript:>>
> Date:
> To: std-pr...@isocpp.org <javascript:>
> Subject: Re: [std-proposals] [C++17][wish-list] first-class function types
> or function-type constraints
>
>
> On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> > It compiles as a pointer/reference to function which is not exactly what
> I
> > meant or quite wanted, it's not as flexible as the first version of foo.
> >
> > The first version would allow pointer/reference to function, a lambda
> > expression that does or does not capture lexical scope (closures), or
> > normal struct with a function call operator overloaded.
>
> That would be std::function.
>
> template < typename Tp >
> auto foo(std::function<Tp(Tp)>) -> Tp;
>
> What are the deficiencies you see in std::function that would require
> making it
> a first-class type?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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/.

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

<div dir=3D"ltr">I'm not sure who you are responding too but I'm guessing i=
t's me, I did not said anything about not using plain template parameter, o=
n the contrary I'd like to be able to "constrain" the template parameter an=
d self-document what the parameter &amp; return types are in the case of fu=
nction templates ones like generic algorithms.<br><br>However I don't feel =
this is the most ideal solution for the future evolution of C++, it seems m=
ore of workaround stop gap solution. IMuy line of thought is that since we =
already have function signatures maybe a better solution is too start from =
here with maybe a basis to evolve C++ with real first-class functions in th=
e future.<br><br>On Tuesday, October 1, 2013 10:22:34 AM UTC+1, R. Martinho=
 Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div>Tha=
t is sorta broken. There is no way to call that function without one of 1) =
explicit template argument or 2) creating a std::function object beforehand=
..</div><div><br></div><div><br></div>Martinho <br><br><br>-------- Original=
 message --------<br>From: Thiago Macieira &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">thi...@macieira.org</a=
>&gt; <br>Date:  <br>To: <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"NihSBwGUxn8J">std-pr...@isocpp.org</a> <br>Subject: Re: [s=
td-proposals] [C++17][wish-list] first-class function types or
  function-type constraints <br> <br><br>On segunda-feira, 30 de setembro d=
e 2013 09:39:09, snk_kid wrote:<br>&gt; It compiles as a pointer/reference =
to function which is not exactly what I <br>&gt; meant or quite wanted, it'=
s not as flexible as the first version of foo.<br>&gt; <br>&gt; The first v=
ersion would allow pointer/reference to function, a lambda <br>&gt; express=
ion that does or does not capture lexical scope (closures), or <br>&gt; nor=
mal struct with a function call operator overloaded.<br><br>That would be s=
td::function.<br><br>template &lt; typename Tp &gt; <br>auto foo(std::funct=
ion&lt;Tp(Tp)&gt;) -&gt; Tp; <br><br>What are the deficiencies you see in s=
td::function that would require making it <br>a first-class type?<br><br>--=
 <br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a><br>&nbsp;&nbsp; Software Architect - Intel Open S=
ource Technology Center<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PGP/GPG: 0x6EF453=
58; fingerprint:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E067 918B B660 DBD1 105C=
&nbsp; 966C 33F5 F005 6EF4 5358<br><br>-- <br><br>--- <br>You received this=
 message because you are subscribed to the Google Groups "ISO C++ Standard =
- Future Proposals" group.<br>To unsubscribe from this group and stop recei=
ving emails from it, send an email to <a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">std-proposal...@<wbr>isocpp.org=
</a>.<br>To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">std-pr...@isocpp.org</a=
>.<br>Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>iso=
cpp.org/group/std-<wbr>proposals/</a>.<br></div></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_152_23938223.1380625139653--

.

------=_Part_95_23594908.1380625204050
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure who you are responding too but I'm guessing it's me, I did not
said anything about not using plain template parameter, on the contrary I'd
like to be able to "constrain" the template parameter and self-document
what the parameter & return types are in the case of function templates
ones like generic algorithms.

However I don't feel this is the most ideal solution for the future
evolution of C++, it seems more of workaround stop gap solution. My line of
thought is that since we already have function signatures maybe a better
solution is too start from here with maybe a basis to evolve C++ with real
first-class functions in the future.

On Tuesday, October 1, 2013 10:22:34 AM UTC+1, R. Martinho Fernandes wrote:
>
> That is sorta broken. There is no way to call that function without one of
> 1) explicit template argument or 2) creating a std::function object
> beforehand.
>
>
> Martinho
>
>
> -------- Original message --------
> From: Thiago Macieira <thi...@macieira.org <javascript:>>
> Date:
> To: std-pr...@isocpp.org <javascript:>
> Subject: Re: [std-proposals] [C++17][wish-list] first-class function types
> or function-type constraints
>
>
> On segunda-feira, 30 de setembro de 2013 09:39:09, snk_kid wrote:
> > It compiles as a pointer/reference to function which is not exactly what
> I
> > meant or quite wanted, it's not as flexible as the first version of foo.
> >
> > The first version would allow pointer/reference to function, a lambda
> > expression that does or does not capture lexical scope (closures), or
> > normal struct with a function call operator overloaded.
>
> That would be std::function.
>
> template < typename Tp >
> auto foo(std::function<Tp(Tp)>) -> Tp;
>
> What are the deficiencies you see in std::function that would require
> making it
> a first-class type?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> 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/.

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

<div dir=3D"ltr">I'm not sure who you are responding too but I'm guessing i=
t's me, I did=20
not said anything about not using plain template parameter, on the=20
contrary I'd like to be able to "constrain" the template parameter and=20
self-document what the parameter &amp; return types are in the case of=20
function templates ones like generic algorithms.<br><br>However I don't=20
feel this is the most ideal solution for the future evolution of C++, it
 seems more of workaround stop gap solution. My line of thought is=20
that since we already have function signatures maybe a better solution=20
is too start from here with maybe a basis to evolve C++ with real=20
first-class functions in the future.<br><br>On Tuesday, October 1, 2013 10:=
22:34 AM UTC+1, R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div><div>That is sorta broken. There is no way to call that =
function without one of 1) explicit template argument or 2) creating a std:=
:function object beforehand.</div><div><br></div><div><br></div>Martinho <b=
r><br><br>-------- Original message --------<br>From: Thiago Macieira &lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NihSBwGUx=
n8J">thi...@macieira.org</a>&gt; <br>Date:  <br>To: <a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">std-pr...@isocpp.=
org</a> <br>Subject: Re: [std-proposals] [C++17][wish-list] first-class fun=
ction types or
  function-type constraints <br> <br><br>On segunda-feira, 30 de setembro d=
e 2013 09:39:09, snk_kid wrote:<br>&gt; It compiles as a pointer/reference =
to function which is not exactly what I <br>&gt; meant or quite wanted, it'=
s not as flexible as the first version of foo.<br>&gt; <br>&gt; The first v=
ersion would allow pointer/reference to function, a lambda <br>&gt; express=
ion that does or does not capture lexical scope (closures), or <br>&gt; nor=
mal struct with a function call operator overloaded.<br><br>That would be s=
td::function.<br><br>template &lt; typename Tp &gt; <br>auto foo(std::funct=
ion&lt;Tp(Tp)&gt;) -&gt; Tp; <br><br>What are the deficiencies you see in s=
td::function that would require making it <br>a first-class type?<br><br>--=
 <br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a><br>&nbsp;&nbsp; Software Architect - Intel Open S=
ource Technology Center<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PGP/GPG: 0x6EF453=
58; fingerprint:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E067 918B B660 DBD1 105C=
&nbsp; 966C 33F5 F005 6EF4 5358<br><br>-- <br><br>--- <br>You received this=
 message because you are subscribed to the Google Groups "ISO C++ Standard =
- Future Proposals" group.<br>To unsubscribe from this group and stop recei=
ving emails from it, send an email to <a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">std-proposal...@<wbr>isocpp.org=
</a>.<br>To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"NihSBwGUxn8J">std-pr...@isocpp.org</a=
>.<br>Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/=
group/std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>iso=
cpp.org/group/std-<wbr>proposals/</a>.<br></div></blockquote></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_95_23594908.1380625204050--

.

On ter=E7a-feira, 1 de outubro de 2013 03:45:26, snk_kid wrote:
> As I've asked Vicente J, I'll say the same to you. Your example may work=
=20
> for simple callable-entities which do not take parameters and have a void=
=20
> return type but as soon as you deal with more complicated callable entiti=
es=20
> in particular ones which are polymophic this may not work well with
> automatic type-deduction rules. An example such as Vicente J's:
>=20
> template < typename Tp, Callable(Tp(Tp)) F >
> auto foo(F f) -> Tp;
> =20
> In this example does this still work with the type deduction rules so=20
> programmers do not have explicity instantiate the first template paramete=
r=20
> and say what the type of 'Tp' is? none has responded to this question yet=
..=20

While I'm familiar with the basics of the concepts-lite, I'm not versed eno=
ugh=20
to be able to tell what would happen to the above. Besides, there are many=
=20
things that may need to be adjusted until 2017.

But suppose the answer were "yes". Suppose that explicit instantiation were=
=20
not necessary with concepts. Would that be enough?

And if it's "no", please make a proposal of what you want and how it would=
=20
work. I still don't get what you want, despite reading all of your emails.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

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

.

--047d7b6d8484de49dc04e7b118a5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>However I don't feel this is the most ideal solution for the future
evolution of C++, it seems more of workaround stop gap solution. My line of
thought is that since we already have function signatures maybe a better
solution is too start from here with maybe a basis to evolve C++ with real
first-class functions in the future.

I'm afraid I don't understand the difference between "first class
functions" and the mechanism provided by std::function. Traditional first
class functions (e.g. in JavaScript) can be of arbitrary size, which
necessitates dynamic memory allocation and virtual dispatch. (Exactly what
std::function does) If that's what you want, you opt-in to it using
std::function.

> In this example does this still work with the type deduction rules so
programmers do not have explicity instantiate the first template parameter
and say what the type of 'Tp' is? none has responded to this question yet.

This is interesting; I suspect a library solution (similar to
std::function's interface) is possible, but I'm no template master. The
difficulty here is that the type you want is not in fact "any callable of
Tp(Tp)", you want "anything callable as if it were Tp(Tp)" -- including
things that are not functions, or things where the argument and return type
are only *convertible to/from* Tp. That means there has to be the type name
of the called type needs to be deduced, not just Tp.

This would be the case even with "first class functions" -- they hold on to
different stuff, and as a result they have to be different types. And so
deducing the type of the function would still be necessary. (std::function
works around this by using type erasure to effectively "forget" that type;
but that necessitates the virtual calls that you're asking to avoid)

I don't think anyone can argue that deducing Tp in the above example is
bad, but what kind of syntax would you propose for it? (the original
email's syntax conflicts with the syntax for function pointers)

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Oct 1, 2013 at 8:25 AM, Thiago Macieira <thiago@macieira.org> wrote=
:

> On ter=E7a-feira, 1 de outubro de 2013 03:45:26, snk_kid wrote:
> > As I've asked Vicente J, I'll say the same to you. Your example may wor=
k
> > for simple callable-entities which do not take parameters and have a vo=
id
> > return type but as soon as you deal with more complicated callable
> entities
> > in particular ones which are polymophic this may not work well with
> > automatic type-deduction rules. An example such as Vicente J's:
> >
> > template < typename Tp, Callable(Tp(Tp)) F >
> > auto foo(F f) -> Tp;
> >
> > In this example does this still work with the type deduction rules so
> > programmers do not have explicity instantiate the first template
> parameter
> > and say what the type of 'Tp' is? none has responded to this question
> yet.
>
> While I'm familiar with the basics of the concepts-lite, I'm not versed
> enough
> to be able to tell what would happen to the above. Besides, there are man=
y
> things that may need to be adjusted until 2017.
>
> But suppose the answer were "yes". Suppose that explicit instantiation we=
re
> not necessary with concepts. Would that be enough?
>
> And if it's "no", please make a proposal of what you want and how it woul=
d
> work. I still don't get what you want, despite reading all of your emails=
..
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr"><div>&gt;However I don&#39;t  feel this is the most ideal =
solution for the future evolution of C++, it seems more of workaround stop =
gap solution. My line of thought is  that since we already have function si=
gnatures maybe a better solution  is too start from here with maybe a basis=
 to evolve C++ with real  first-class functions in the future.</div>

<div>=A0</div><div>I&#39;m afraid I don&#39;t understand the difference bet=
ween &quot;first class functions&quot; and the mechanism provided by std::f=
unction. Traditional first class functions (e.g. in JavaScript) can be of a=
rbitrary size, which necessitates dynamic memory allocation and virtual dis=
patch. (Exactly what std::function does) If that&#39;s what you want, you o=
pt-in to it using std::function. </div>

<div>=A0</div><div>&gt; In this example does this still work with the type =
deduction rules so programmers do not have explicity instantiate the first =
template parameter and say what the type of &#39;Tp&#39; is? none has respo=
nded to this question yet.</div>

<div>=A0</div><div>This is interesting; I suspect a library solution (simil=
ar to std::function&#39;s interface) is possible, but I&#39;m no template m=
aster. The difficulty here is that the type you want is not in fact &quot;a=
ny callable of Tp(Tp)&quot;, you want &quot;anything callable as if it were=
 Tp(Tp)&quot; -- including things that are not functions, or things where t=
he argument and return type are only *convertible to/from* Tp. That means t=
here has to be the type name of the called type needs to be deduced, not ju=
st=A0Tp.</div>

<div>=A0</div><div>This would be the case even with &quot;first class funct=
ions&quot; -- they hold on to different stuff, and as a result they have to=
 be different types. And so deducing the type of the function=A0would still=
 be necessary. (std::function works around this by using type erasure to ef=
fectively &quot;forget&quot; that type; but that necessitates the virtual c=
alls that you&#39;re asking to avoid)</div>

<div>=A0</div><div>I don&#39;t think anyone can argue that deducing Tp in t=
he above example is bad, but what kind of syntax would you propose for it? =
(the original email&#39;s syntax conflicts with the syntax for function poi=
nters)</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Oct 1, 2013 at 8:25 AM, Thiago M=
acieira <span dir=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=
=3D"_blank">thiago@macieira.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im">On ter=E7a-feira, 1 de outubro de 2013 03:45:26, snk_kid =
wrote:<br>
&gt; As I&#39;ve asked Vicente J, I&#39;ll say the same to you. Your exampl=
e may work<br>
&gt; for simple callable-entities which do not take parameters and have a v=
oid<br>
&gt; return type but as soon as you deal with more complicated callable ent=
ities<br>
&gt; in particular ones which are polymophic this may not work well with<br=
>
&gt; automatic type-deduction rules. An example such as Vicente J&#39;s:<br=
>
&gt;<br>
&gt; template &lt; typename Tp, Callable(Tp(Tp)) F &gt;<br>
&gt; auto foo(F f) -&gt; Tp;<br>
&gt;<br>
&gt; In this example does this still work with the type deduction rules so<=
br>
&gt; programmers do not have explicity instantiate the first template param=
eter<br>
&gt; and say what the type of &#39;Tp&#39; is? none has responded to this q=
uestion yet.<br>
<br>
</div>While I&#39;m familiar with the basics of the concepts-lite, I&#39;m =
not versed enough<br>
to be able to tell what would happen to the above. Besides, there are many<=
br>
things that may need to be adjusted until 2017.<br>
<br>
But suppose the answer were &quot;yes&quot;. Suppose that explicit instanti=
ation were<br>
not necessary with concepts. Would that be enough?<br>
<br>
And if it&#39;s &quot;no&quot;, please make a proposal of what you want and=
 how it would<br>
work. I still don&#39;t get what you want, despite reading all of your emai=
ls.<br>
<div class=3D"im HOEnZb"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6d8484de49dc04e7b118a5--

.

On Mon, Sep 30, 2013 at 11:54 AM, snk_kid <korcan.hussein@googlemail.com> wrote:
> I'd like to have some kind of true first-class function types or some
> mechanism of declaring type constraints which specify & document to other
> programmers what is expected of a callable entity parameter of template
> function, when you have code like this:
>
> template < typename Function, typename Tp >
> auto foo(Function fn) -> Tp;
>
> It's impossible to know what the expected parameter and return types must be
> without looking at the definition of the function or trying to figure them
> out from compile-errors, if you're lucky the author may have properly
> documented what the types are but that's usually not the case especially for
> projects that are still in flux.
>
> Even with documentation this still isn't as good as having this as part of
> the type system and having self-documenting code. I wish I could write C++
> code something like this:
>
> template < typename Tp >
> auto foo(Tp fn(Tp)) -> Tp;

If I understand correctly, this works

  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3729.html

And it's planned for Fundamental TS.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

--089e012947847dbcd904e7b40ca6
Content-Type: text/plain; charset=ISO-8859-1

>invocation_type<Fn(ArgTypes...)>

"Fn" is still named, so argument deduction wouldn't work.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Oct 1, 2013 at 11:36 AM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, Sep 30, 2013 at 11:54 AM, snk_kid <korcan.hussein@googlemail.com>
> wrote:
> > I'd like to have some kind of true first-class function types or some
> > mechanism of declaring type constraints which specify & document to other
> > programmers what is expected of a callable entity parameter of template
> > function, when you have code like this:
> >
> > template < typename Function, typename Tp >
> > auto foo(Function fn) -> Tp;
> >
> > It's impossible to know what the expected parameter and return types
> must be
> > without looking at the definition of the function or trying to figure
> them
> > out from compile-errors, if you're lucky the author may have properly
> > documented what the types are but that's usually not the case especially
> for
> > projects that are still in flux.
> >
> > Even with documentation this still isn't as good as having this as part
> of
> > the type system and having self-documenting code. I wish I could write
> C++
> > code something like this:
> >
> > template < typename Tp >
> > auto foo(Tp fn(Tp)) -> Tp;
>
> If I understand correctly, this works
>
>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3729.html
>
> And it's planned for Fundamental TS.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>&gt;<font face=3D"Courier New">invocation_type&lt;Fn(=
ArgTypes...)&gt;</font> </div><div>=A0</div><div>&quot;Fn&quot; is still na=
med, so argument deduction wouldn&#39;t work.</div></div><div class=3D"gmai=
l_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Oct 1, 2013 at 11:36 AM, Zhihao =
Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blan=
k">zy@miator.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Mon, Sep 30, 2013 at 11:54 AM, snk_kid &lt;<a href=3D"mailto:korcan.huss=
ein@googlemail.com">korcan.hussein@googlemail.com</a>&gt; wrote:<br>
&gt; I&#39;d like to have some kind of true first-class function types or s=
ome<br>
&gt; mechanism of declaring type constraints which specify &amp; document t=
o other<br>
&gt; programmers what is expected of a callable entity parameter of templat=
e<br>
&gt; function, when you have code like this:<br>
&gt;<br>
&gt; template &lt; typename Function, typename Tp &gt;<br>
&gt; auto foo(Function fn) -&gt; Tp;<br>
&gt;<br>
&gt; It&#39;s impossible to know what the expected parameter and return typ=
es must be<br>
&gt; without looking at the definition of the function or trying to figure =
them<br>
&gt; out from compile-errors, if you&#39;re lucky the author may have prope=
rly<br>
&gt; documented what the types are but that&#39;s usually not the case espe=
cially for<br>
&gt; projects that are still in flux.<br>
&gt;<br>
&gt; Even with documentation this still isn&#39;t as good as having this as=
 part of<br>
&gt; the type system and having self-documenting code. I wish I could write=
 C++<br>
&gt; code something like this:<br>
&gt;<br>
&gt; template &lt; typename Tp &gt;<br>
&gt; auto foo(Tp fn(Tp)) -&gt; Tp;<br>
<br>
If I understand correctly, this works<br>
<br>
=A0 <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n372=
9.html" target=3D"_blank">http://www.open-std.org/JTC1/SC22/WG21/docs/paper=
s/2013/n3729.html</a><br>
<br>
And it&#39;s planned for Fundamental TS.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e012947847dbcd904e7b40ca6--

.