------=_Part_1310_19932049.1379080487244
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, September 12, 2013 11:59:00 PM UTC+8, R. Martinho Fernandes
wrote:
>
> N3727 here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3727.html
>
> In my view there is an important thing missing from this
> specification: text that states that those overloads do not
> participate on overload resolution unless the corresponding relevant
> expression is well-formed.
>
> The first overload, with result_of, already has that behaviour since
> result_of lacks a member type when that's the case, so it's actually
> ok.
>
> But the second overload will always take part in overload resolution,
> even if the relevant call expression is not well-formed. I think this
> is unfortunate and requires jumping through hoops if you are making a
> decision on whether some type is "invokable with a given result type".
>

I think you mean the third overload? The first and second both use result_ofas you described.

It's a surprising omission. The author may have been unable to resolve the
template recursion within overload resolution as the third tries to
delegate to the first two, but finds itself to be a candidate as well, even
if the number of (template) arguments is wrong.

The obvious resolution is to OR together all the SFINAE from the first two
overloads into the third. But it's not just Boolean conditions, but the
well-formedness of the return value ::types which are computed differently.
These cannot be combined.

Generally such a fallback overload can avoid self-reference by qualifying
its own name where it would be an unintentional candidate. Qualified name
lookup only finds names visible at the point of declaration, not names in
scope at the point of instantiation or found by ADL.

template<typename Return, typename Functor, typename... Args>
decltype( ::std::invoke( declval< Functor >(), declval< Args >() ) )
invoke(Functor&& f, Args&&... args)
    { return invoke(std::forward<Functor>(f), std::forward<Args>(args)...);
}

--

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

<div dir=3D"ltr"><br><br>On Thursday, September 12, 2013 11:59:00 PM UTC+8,=
 R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">N=
3727 here: <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3727.html" target=3D"_blank">http://open-std.org/jtc1/sc22/<wbr>wg21/docs/p=
apers/2013/n3727.<wbr>html</a>
<br>
<br>In my view there is an important thing missing from this
<br>specification: text that states that those overloads do not
<br>participate on overload resolution unless the corresponding relevant
<br>expression is well-formed.
<br>
<br>The first overload, with result_of, already has that behaviour since
<br>result_of lacks a member type when that's the case, so it's actually
<br>ok.
<br>
<br>But the second overload will always take part in overload resolution,
<br>even if the relevant call expression is not well-formed. I think this
<br>is unfortunate and requires jumping through hoops if you are making a
<br>decision on whether some type is "invokable with a given result type".
<br></blockquote><div><br>I think you mean the third overload? The first an=
d second both use <span style=3D"font-family: courier new,monospace;">resul=
t_of</span> as you described. <br><br>It's a surprising omission. The autho=
r may have been unable to resolve the template recursion within overload re=
solution as the third tries to delegate to the first two, but finds itself =
to be a candidate as well, even if the number of (template) arguments is wr=
ong.<br><br>The obvious resolution is to OR together all the SFINAE from th=
e first two overloads into the third. But it's not just Boolean conditions,=
 but the well-formedness of the return value <span style=3D"font-family: co=
urier new,monospace;">::type</span>s which are computed differently. These =
cannot be combined.<br><br>Generally such a fallback overload can avoid sel=
f-reference by qualifying its own name where it would be an unintentional c=
andidate. Qualified name lookup only finds names visible at the point of de=
claration, not names in scope at the point of instantiation or found by ADL=
..<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Return</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"col=
or: #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">Functor</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">t=
ypename</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Args</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">invok=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> declval</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Functor</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;(),</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> declval</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">Args</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;()=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan 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;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>invoke</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Functor</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;...</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> args</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> invoke</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">forward</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Functor</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt=
;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">forward</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Args</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">)...);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
/div></code></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 />

------=_Part_1310_19932049.1379080487244--

.

------=_Part_1402_21386799.1379080634291
Content-Type: text/plain; charset=ISO-8859-1

Oops, declval< Args >() .... I didn't actually compile with a real compiler
but it should work. :v)

--

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

<div dir=3D"ltr"><code><span style=3D"color:#000"><span style=3D"font-famil=
y: arial,sans-serif;">Oops, </span>declval</span><span style=3D"color:#660"=
>&lt;</span><span style=3D"color:#000"> </span><span style=3D"color:#606">A=
rgs</span><span style=3D"color:#660"> &gt;()</span></code><code><span style=
=3D"color:#606"></span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">...<font face=3D"arial,sans-serif"><font color=3D"#000000">. I di=
dn't actually compile with a real compiler but it should work. :v)</font><b=
r></font></span></code></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_1402_21386799.1379080634291--

.

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



On Friday, September 13, 2013 9:57:14 PM UTC+8, David Krauss wrote:
>
> Oops, declval< Args >() .... I didn't actually compile with a real=20
> compiler but it should work. :v)
>

=85 And I forgot to use std::is_convertible. Left as exercise for the reade=
r.=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_56_7765833.1379080920462
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, September 13, 2013 9:57:14 PM UTC+8, Da=
vid Krauss wrote:<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"><code><span style=3D"color:#000"><span style=3D"font-family:arial,sans-=
serif">Oops, </span>declval</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#606">Args</span><span=
 style=3D"color:#660"> &gt;()</span></code><code><span style=3D"color:#606"=
></span><span style=3D"color:#000"> </span><span style=3D"color:#660">...<f=
ont face=3D"arial,sans-serif"><font color=3D"#000000">. I didn't actually c=
ompile with a real compiler but it should work. :v)</font><br></font></span=
></code></div></blockquote><div><br>=85 And I forgot to use <span style=3D"=
font-family: courier new,monospace;">std::is_convertible</span>. Left as ex=
ercise for the reader. <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_56_7765833.1379080920462--

.

------=_Part_346_6282403.1379271201347
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable



W dniu pi=B1tek, 13 wrze=B6nia 2013 15:54:47 UTC+2 u=BFytkownik David Kraus=
s=20
napisa=B3:
>
>
>
> On Thursday, September 12, 2013 11:59:00 PM UTC+8, R. Martinho Fernandes=
=20
> wrote:
>>
>> N3727 here:=20
>> http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3727.html=20
>>
>> In my view there is an important thing missing from this=20
>> specification: text that states that those overloads do not=20
>> participate on overload resolution unless the corresponding relevant=20
>> expression is well-formed.=20
>>
>> The first overload, with result_of, already has that behaviour since=20
>> result_of lacks a member type when that's the case, so it's actually=20
>> ok.=20
>>
>> But the second overload will always take part in overload resolution,=20
>> even if the relevant call expression is not well-formed. I think this=20
>> is unfortunate and requires jumping through hoops if you are making a=20
>> decision on whether some type is "invokable with a given result type".=
=20
>>
>
> I think you mean the third overload? The first and second both use=20
> result_of as you described.=20
>
> It's a surprising omission. The author may have been unable to resolve th=
e=20
> template recursion within overload resolution as the third tries to=20
> delegate to the first two, but finds itself to be a candidate as well, ev=
en=20
> if the number of (template) arguments is wrong.
>
> The third overload used unqualified name lookup but will not find itself=
=20
as candidate function, because the overload resolution mechanism work in=20
following steps:
  - deduce the argument for function template - that process requires only=
=20
looking to the function signature, unless return type deduction is used.=20
For the third overload the deduction process will fail because the Ret=20
parameter cannot be deduced for the arguments.
  - construct the candidates set using normal function and template=20
functions for which deduction process succeed - this will exclude the third=
=20
overload and prevents recursion in template instation.
So the code proposed in implementation section works correctly.
=20

> The obvious resolution is to OR together all the SFINAE from the first tw=
o=20
> overloads into the third. But it's not just Boolean conditions, but the=
=20
> well-formedness of the return value ::types which are computed=20
> differently. These cannot be combined.
>
> Generally such a fallback overload can avoid self-reference by qualifying=
=20
> its own name where it would be an unintentional candidate. Qualified name=
=20
> lookup only finds names visible at the point of declaration, not names in=
=20
> scope at the point of instantiation or found by ADL.
>
> template<typename Return, typename Functor, typename... Args>
> decltype( ::std::invoke( declval< Functor >(), declval< Args >() ) )
> invoke(Functor&& f, Args&&... args)
>     { return invoke(std::forward<Functor>(f), std::forward<Args>(args
> )...); }
>
>

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

<div dir=3D"ltr"><br><br>W dniu pi=B1tek, 13 wrze=B6nia 2013 15:54:47 UTC+2=
 u=BFytkownik David Krauss napisa=B3:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><br><br>On Thursday, September 12, 2013 11:59:00 PM=
 UTC+8, R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>N3727 here: <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2013=
/n3727.html" target=3D"_blank">http://open-std.org/jtc1/sc22/<wbr>wg21/docs=
/papers/2013/n3727.<wbr>html</a>
<br>
<br>In my view there is an important thing missing from this
<br>specification: text that states that those overloads do not
<br>participate on overload resolution unless the corresponding relevant
<br>expression is well-formed.
<br>
<br>The first overload, with result_of, already has that behaviour since
<br>result_of lacks a member type when that's the case, so it's actually
<br>ok.
<br>
<br>But the second overload will always take part in overload resolution,
<br>even if the relevant call expression is not well-formed. I think this
<br>is unfortunate and requires jumping through hoops if you are making a
<br>decision on whether some type is "invokable with a given result type".
<br></blockquote><div><br>I think you mean the third overload? The first an=
d second both use <span style=3D"font-family:courier new,monospace">result_=
of</span> as you described. <br><br>It's a surprising omission. The author =
may have been unable to resolve the template recursion within overload reso=
lution as the third tries to delegate to the first two, but finds itself to=
 be a candidate as well, even if the number of (template) arguments is wron=
g.<br><br></div></div></blockquote><div>The third overload used unqualified=
 name lookup but will not find itself as candidate function, because the ov=
erload resolution mechanism work in following steps:<br>&nbsp; - deduce the=
 argument for function template - that process requires only looking to the=
 function signature, unless return type deduction is used. For the third ov=
erload the deduction process will fail because the Ret parameter cannot be =
deduced for the arguments.<br>&nbsp; - construct the candidates set using n=
ormal function and template functions for which deduction process succeed -=
 this will exclude the third overload and prevents recursion in template in=
station.<br>So the code proposed in implementation section works correctly.=
<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>The obvious resolution is to OR together all the SFINAE from the fi=
rst two overloads into the third. But it's not just Boolean conditions, but=
 the well-formedness of the return value <span style=3D"font-family:courier=
 new,monospace">::type</span>s which are computed differently. These cannot=
 be combined.<br><br>Generally such a fallback overload can avoid self-refe=
rence by qualifying its own name where it would be an unintentional candida=
te. Qualified name lookup only finds names visible at the point of declarat=
ion, not names in scope at the point of instantiation or found by ADL.<br><=
br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187=
,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div>=
<span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</=
span><span style=3D"color:#008">typename</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">Return</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">typena=
me</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Func=
tor</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#008">typename</span><span style=3D"color:#660">.=
...</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Args=
</span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#008">decltype</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000"> </span><span style=3D"color:#660">::<=
/span><span style=3D"color:#000">std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">invoke</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000"> declval</span><span style=3D"color:#660">&l=
t;</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Func=
tor</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&gt=
;(),</span><span style=3D"color:#000"> declval</span><span style=3D"color:#=
660">&lt;</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">Args</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>&gt;()</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"><br>invoke</span><span style=3D"color:#660">=
(</span><span style=3D"color:#606">Functor</span><span style=3D"color:#660"=
>&amp;&amp;</span><span style=3D"color:#000"> f</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606"=
>Args</span><span style=3D"color:#660">&amp;&amp;...</span><span style=3D"c=
olor:#000"> args</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#660">{</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#008">return</span><span=
 style=3D"color:#000"> invoke</span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">forward</span><span style=3D"color:#660">&lt;</span><s=
pan style=3D"color:#606">Functor</span><span style=3D"color:#660">&gt;(</sp=
an><span style=3D"color:#000">f</span><span style=3D"color:#660"><wbr>),</s=
pan><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</sp=
an><span style=3D"color:#000">forward</span><span style=3D"color:#660">&lt;=
</span><span style=3D"color:#606">Args</span><span style=3D"color:#660">&gt=
;(</span><span style=3D"color:#000">args</span><span style=3D"color:#660">)=
....);</span><span style=3D"color:#000"> </span><span style=3D"color:#660">}=
</span><span style=3D"color:#000"><br></span></div></code></div><br></div><=
/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_346_6282403.1379271201347--

.

------=_Part_2240_20500064.1379273660757
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

W dniu czwartek, 12 wrze=B6nia 2013 17:59:00 UTC+2 u=BFytkownik R. Martinho=
=20
Fernandes napisa=B3:
>
> N3727 here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3727.htm=
l=20
>
> In my view there is an important thing missing from this=20
> specification: text that states that those overloads do not=20
> participate on overload resolution unless the corresponding relevant=20
> expression is well-formed.=20
>
> The same argument may be apply for all standard algorithms or copy/move=
=20
constructors
of containers - they should be not found by overload resolutions unless=20
types match the constraints=20
of parameters (iterator, predicates). At this moment such constraint are=20
only placed in standard for
situations when the generic version may cause ambiguity with better=20
candidate (eg. pair constructors).

Firstly I think that at this moment test basing of result_of<>::type,=20
because they will work correctly only for function
pointer and predicates with non-template methods (for ex. generic lambdas=
=20
will not if return type is specified),=20
so using invoke function to check if function is callable with specified=20
number of arguments will give false-
positive results.

Also invoke is not intended to be an extensions point to the standard=20
functor presented in the <functional>
header (bind, mem_fn) - the user provided overload of invoke> should not be=
=20
considered=20
by implementation of mentioned components - the invoke depends on INVOKE=20
pseudo-expressions, like other
functional components, by their are not required to use invoke function.

So unless the mechanism better that enable-if is introduced in the standard=
=20
(concepts-lite) I am a bit
reculant not impose such requirements by placing notes in standard text.

Of course I may miss some important use case for such behavior, so I am=20
open to the discussions if
this will be actually beneficial to place the constrains on this function=
=20
before concepts-lite are introduced.

The first overload, with result_of, already has that behaviour since=20
> result_of lacks a member type when that's the case, so it's actually=20
> ok.=20
>

But the second overload will always take part in overload resolution,=20
> even if the relevant call expression is not well-formed. I think this=20
> is unfortunate and requires jumping through hoops if you are making a=20
> decision on whether some type is "invokable with a given result type".=20
>
> But as I mentioned before, such test are not reliable in unconstrained=20
code.
Also you may make such decision using result_of<>.

Mit freundlichen Gr=FC=DFen,=20
>
> Martinho=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_2240_20500064.1379273660757
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">W dniu czwartek, 12 wrze=B6nia 2013 17:59:00 UTC+2 u=BFytk=
ownik R. Martinho Fernandes napisa=B3:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">N3727 here: <a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2013/n3727.html" target=3D"_blank">http://open-std.org/jtc1/sc22/<wbr>wg=
21/docs/papers/2013/n3727.<wbr>html</a>
<br>
<br>In my view there is an important thing missing from this
<br>specification: text that states that those overloads do not
<br>participate on overload resolution unless the corresponding relevant
<br>expression is well-formed.
<br>
<br></blockquote><div>The same argument may be apply for all standard algor=
ithms or copy/move constructors<br>of containers - they should be not found=
 by overload resolutions unless types match the constraints <br>of paramete=
rs (iterator, predicates). At this moment such constraint are only placed i=
n standard for<br>situations when the generic version may cause ambiguity w=
ith better candidate (eg. pair constructors).<br><br>Firstly I think that a=
t this moment test basing of result_of&lt;&gt;::type, because they will wor=
k correctly only for function<br>pointer and predicates with non-template m=
ethods (for ex. generic lambdas will not if return type is specified), <br>=
so using invoke function to check if function is callable with specified nu=
mber of arguments will give false-<br>positive results.<br><br>Also invoke =
is not intended to be an extensions point to the standard functor presented=
 in the &lt;functional&gt;<br>header (bind, mem_fn) - the user provided ove=
rload of invoke&gt; should not be considered <br>by implementation of menti=
oned components - the invoke depends on INVOKE pseudo-expressions, like oth=
er<br>functional components, by their are not required to use invoke functi=
on.<br><br>So unless the mechanism better that enable-if is introduced in t=
he standard (concepts-lite) I am a bit<br>reculant not impose such requirem=
ents by placing notes in standard text.<br><br>Of course I may miss some im=
portant use case for such behavior, so I am open to the discussions if<br>t=
his will be actually beneficial to place the constrains on this function be=
fore concepts-lite are introduced.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">The first overload, with result_of, already has that beha=
viour since
<br>result_of lacks a member type when that's the case, so it's actually
<br>ok.
<br></blockquote><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">But the second overload will always take part in overload resolution,
<br>even if the relevant call expression is not well-formed. I think this
<br>is unfortunate and requires jumping through hoops if you are making a
<br>decision on whether some type is "invokable with a given result type".
<br>
<br></blockquote><div>But as I mentioned before, such test are not reliable=
 in unconstrained code.<br>Also you may make such decision using result_of&=
lt;&gt;.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Mit freu=
ndlichen Gr=FC=DFen,
<br>
<br>Martinho
<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_2240_20500064.1379273660757--

.

------=_Part_2768_22487963.1379284055844
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 16, 2013 2:53:21 AM UTC+8, toma...@gmail.com wrote:
>
>
> The third overload used unqualified name lookup but will not find itself
> as candidate function, because the overload resolution mechanism work in
> following steps:
>   - deduce the argument for function template - that process requires only
> looking to the function signature, unless return type deduction is used.
> For the third overload the deduction process will fail because the Ret
> parameter cannot be deduced for the arguments.
>   - construct the candidates set using normal function and template
> functions for which deduction process succeed - this will exclude the third
> overload and prevents recursion in template instation.
> So the code proposed in implementation section works correctly.
>

We're talking about restricting the third overload to valid function
arguments, as the first two are. The third overload as proposed has
different semantics from the other two. It participates in the candidate
set even if the object is not invocable with the given arguments.

Attempting to predicate the participation of one function upon the
participation of other functions with the same name but different
(template) arguments leads to the problem I solved.

Obviously there is no recursion in the proposal.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, September 16, 2013 2:53:21 AM UTC+8, to=
ma...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>The third overload used unqualified name lookup but will not f=
ind itself as candidate function, because the overload resolution mechanism=
 work in following steps:<br><div>&nbsp; - deduce the argument for function=
 template - that process requires only looking to the function signature, u=
nless return type deduction is used. For the third overload the deduction p=
rocess will fail because the Ret parameter cannot be deduced for the argume=
nts.<br>&nbsp; - construct the candidates set using normal function and tem=
plate functions for which deduction process succeed - this will exclude the=
 third overload and prevents recursion in template instation.<br>So the cod=
e proposed in implementation section works correctly.<br></div></div></bloc=
kquote><div><br>We're talking about restricting the third overload to valid=
 function arguments, as the first two are. The third overload as proposed h=
as different semantics from the other two. It participates in the candidate=
 set even if the object is not invocable with the given arguments.<br><br>A=
ttempting to predicate the participation of one function upon the participa=
tion of other functions with the same name but different (template) argumen=
ts leads to the problem I solved.<br><br>Obviously there is no recursion in=
 the proposal.</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_2768_22487963.1379284055844--

.