Topic: type signatures or constraints for callable entity
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Sun, 8 Sep 2013 04:13:11 -0700 (PDT)
Raw View
------=_Part_9_20900942.1378638791289
Content-Type: text/plain; charset=ISO-8859-1
type signatures or constraints for callable entity type parameters
Something I'd like to see fixed in the near future is being able to specify
in the type system (and also get documentation-for-free) is what the
parameters & return type must be of a callable entity template parameter.
What I mean by this is currently when writing a higher-order function in
C++ such as:
template < typename Function >
void foo(Function bar);
Without looking at the definition of 'foo' or without documentation it is
impossible to tell what kind of parameters/return type is expected of 'fn'.
Maybe a template constraint such as this would be possible:
template< typename Fn > requires Function<Fn, void (int,int) >()
void foo(Fn bar);
But I'm not sure if you could write such a constraint to full genericity
and support higher-rank polymorphism (a higher-order function where the
function parameters are itself polymorphic).
To me this solution seems less than ideal, limiting and verbose (especially
when adding more constraints for other type parameters). Ideally C++ should
have true first-class function types and not have to rely on template
ducking type to achieve higher-order functions in C++.
--
---
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_9_20900942.1378638791289
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">type signatures or constraints for callable entity type pa=
rameters<br><br>Something I'd like to see fixed in the near future is being=
able to specify in the type system (and also get documentation-for-free) i=
s what the parameters & return type must be of a callable entity templa=
te parameter. What I mean by this is currently when writing a higher-order =
function in C++ such as:<br><br>template < typename Function ><br>voi=
d foo(Function bar);<br><br>Without looking at the definition of 'foo' or w=
ithout documentation it is impossible to tell what kind of parameters/retur=
n type is expected of 'fn'.<br><br>Maybe a template constraint such as this=
would be possible:<br><br>template< typename Fn > requires Function&=
lt;Fn, void (int,int) >()<br>void foo(Fn bar);<br><br>But I'm not sure i=
f you could write such a constraint to full genericity and support higher-r=
ank polymorphism (a higher-order function where the function parameters are=
itself polymorphic).<br><br>To me this solution seems less than ideal, lim=
iting and verbose (especially when adding more constraints for other type p=
arameters). Ideally C++ should have true first-class function types and not=
have to rely on template ducking type to achieve higher-order functions in=
C++.<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_9_20900942.1378638791289--
.
Author: snk_kid <korcan.hussein@googlemail.com>
Date: Sun, 8 Sep 2013 04:14:33 -0700 (PDT)
Raw View
------=_Part_1045_23592723.1378638873207
Content-Type: text/plain; charset=ISO-8859-1
Something I'd like to see fixed in the near future is being able to specify
in the type system (and also get documentation-for-free) is what the
parameters & return type must be of a callable entity template parameter.
What I mean by this is currently when writing a higher-order function in
C++ such as:
template < typename Function >
void foo(Function bar);
Without looking at the definition of 'foo' or without documentation it is
impossible to tell what kind of parameters/return type is expected of 'fn'.
Maybe a template constraint such as this would be possible:
template< typename Fn > requires Function<Fn, void (int,int) >()
void foo(Fn bar);
But I'm not sure if you could write such a constraint to full genericity
and support higher-rank polymorphism (a higher-order function where the
function parameters are itself polymorphic).
To me this solution seems less than ideal, limiting and verbose (especially
when adding more constraints for other type parameters). Ideally C++ should
have true first-class function types and not have to rely on template
ducking type to achieve higher-order functions in C++.
--
---
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_1045_23592723.1378638873207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Something I'd like to see fixed in the near future is bein=
g able to specify in the type system (and also get documentation-for-free) =
is what the parameters & return type must be of a callable entity templ=
ate parameter. What I mean by this is currently when writing a higher-order=
function in C++ such as:<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" 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"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Function</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> bar</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span></div></code></div><br><br><br>Without looking at the definition =
of 'foo' or without documentation it is impossible to tell what kind of par=
ameters/return type is expected of 'fn'.<br><br>Maybe a template constraint=
such as this would be possible:<br><br><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bo=
rder-style: solid; 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: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Fn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> requires </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Function</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span styl=
e=3D"color: #606;" 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: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</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: #6=
60;" class=3D"styled-by-prettify">>()</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Fn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><br>But I'm not sure if you could write such a constraint to ful=
l genericity and support higher-rank polymorphism (a higher-order function =
where the function parameters are itself polymorphic).<br><br>To me this so=
lution seems less than ideal, limiting and verbose (especially when adding =
more constraints for other type parameters). Ideally C++ should have true f=
irst-class function types and not have to rely on template ducking type to =
achieve higher-order functions in C++.<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_1045_23592723.1378638873207--
.