------=_Part_4641_1457003317.1441858588725
Content-Type: multipart/alternative;
 boundary="----=_Part_4642_1776152968.1441858588725"

------=_Part_4642_1776152968.1441858588725
Content-Type: text/plain; charset=UTF-8

Hello everyone,

A usability problem I found and it is quite annoying and could show in many
scenarios,
and potentially in generic scenarios, is the following one:


    void f();
    void f(int, float);
    void f(int);


    auto bound_f = bind(f, std::placeholders::_1, 3.8f); //Ambigous call

Instead we must do this, which is annoying, but also advanced for
non-expert users (usability problem):

    auto bound_f = bind (static_cast<void (*)(int, float)>(f),
std::placeholders::_1, 3.8f);


The template rules cannot deduce the correct f because it is overloaded. So
I did something like this:

#define overloaded(f) [](auto &&... args) { return
f(forward<decltype(args)>(args)...); }


Now I can do:

   auto bound_f = bind(overloaded(f), std::placeholders::_1, 3.8f);

This problem will also happen with functions such as
std::experimental::apply and std::invoke (c++17).

   std::tuple<int> args{5};
   apply(f, args); //Ambiguous

   apply(overloaded(f), args); //Correct


Note that this overloaded trick can only be done through a macro. If you
try to use a function called overloaded,
the deduced function is still ambiguous when passed as a parameter.


My general idea for the proposal would be to use the as-if rule and in the
case of ambiguous resolution on overloading,
propose that the function is chosen as-if wrapped in that lambda:

   apply(f, args); //as if called by apply(overloaded(f), args); because f
would be ambiguous.

I believe this is backwards compatible, but I am not sure if it could cover
all cases.

Is there any interest in solving this problem?


--

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

<div dir=3D"ltr">Hello everyone,<br><br>A usability problem I found and it =
is quite annoying and could show in many scenarios,<br>and potentially in g=
eneric scenarios, is the following one:<br><br><br>=C2=A0=C2=A0=C2=A0 void =
f();<br>=C2=A0=C2=A0=C2=A0 void f(int, float);<br>=C2=A0=C2=A0=C2=A0 void f=
(int);<br><br><br>=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind(f, std::placehol=
ders::_1, 3.8f); //Ambigous call<br>=C2=A0<br>Instead we must do this, whic=
h is annoying, but also advanced for non-expert users (usability problem):<=
br><br>=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind (static_cast&lt;void (*)(in=
t, float)&gt;(f), std::placeholders::_1, 3.8f);<br><br><br>The template rul=
es cannot deduce the correct f because it is overloaded. So I did something=
 like this:<br><br>#define overloaded(f) [](auto &amp;&amp;... args) { retu=
rn f(forward&lt;decltype(args)&gt;(args)...); }<br><br><br>Now I can do:<br=
><br>=C2=A0=C2=A0 auto bound_f =3D bind(overloaded(f), std::placeholders::_=
1, 3.8f);<br><br>This problem will also happen with functions such as std::=
experimental::apply and std::invoke (c++17).<br><br>=C2=A0=C2=A0 std::tuple=
&lt;int&gt; args{5};<br>=C2=A0=C2=A0 apply(f, args); //Ambiguous<br><br>=C2=
=A0=C2=A0 apply(overloaded(f), args); //Correct<br><br><br>Note that this o=
verloaded trick can only be done through a macro. If you try to use a funct=
ion called overloaded,<br>the deduced function is still ambiguous when pass=
ed as a parameter.<br><br><br>My general idea for the proposal would be to =
use the as-if rule and in the case of ambiguous resolution on overloading,<=
br>propose that the function is chosen as-if wrapped in that lambda:<br><br=
>=C2=A0=C2=A0 apply(f, args); //as if called by apply(overloaded(f), args);=
 because f would be ambiguous.<br><br>I believe this is backwards compatibl=
e, but I am not sure if it could cover all cases.<br><br>Is there any inter=
est in solving this problem?<br><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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4642_1776152968.1441858588725--
------=_Part_4641_1457003317.1441858588725--

.

--Apple-Mail=_1F082AA6-39C1-4266-A7AD-1AECE78C8035
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9310, at 12:16 PM, Germ=C3=A1n Diago <germandiag=
o@gmail.com> wrote:
>=20
> Is there any interest in solving this problem?

Certainly. See N3617 <http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n=
3617.htm> which opened EWG 65 <http://wg21.cmeerw.net/ewg/issue65>.

The problem appears like it could be amenable to expression aliases. Howeve=
r, it=E2=80=99s tricky to fit expression aliases into either the type syste=
m or into parameter passing. Perhaps you could have an alias parameter decl=
ared with auto to imply function templating.

decltype(auto) bind5( auto [&]f ) {
    return f( 5 ); // Evaluate the argument expression here.
}

Deducing class template parameters from an initializer (i.e. parameter) cou=
ld also help to decide exactly what the wrapper is, allowing e.g. implicit =
conversion of the overloaded name to std::function when the receiver isn=E2=
=80=99t a template.

Sorry to be vague, but my personal suspicion is that the best solution lies=
 in the intersection of these several speculative solution spaces.

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

--Apple-Mail=_1F082AA6-39C1-4266-A7AD-1AECE78C8035
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9310, at 12:16 PM, Germ=C3=A1n Diago &lt;<a href=3D"mailto:germandia=
go@gmail.com" class=3D"">germandiago@gmail.com</a>&gt; wrote:</div><br clas=
s=3D"Apple-interchange-newline"><div class=3D""><span style=3D"font-family:=
 Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; flo=
at: none; display: inline !important;" class=3D"">Is there any interest in =
solving this problem?</span><br style=3D"font-family: Helvetica; font-size:=
 12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""></div></block=
quote></div><br class=3D""><div class=3D"">Certainly. See&nbsp;<a href=3D"h=
ttp://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3617.htm" class=3D"">N3=
617</a>&nbsp;which opened&nbsp;<a href=3D"http://wg21.cmeerw.net/ewg/issue6=
5" class=3D"">EWG 65</a>.</div><div class=3D""><br class=3D""></div><div cl=
ass=3D"">The problem <i class=3D"">appears</i> like it could be amenable to=
 expression aliases. However, it=E2=80=99s tricky to fit expression aliases=
 into either the type system or into parameter passing. Perhaps you could h=
ave an alias parameter declared with <font face=3D"Courier" class=3D"">auto=
</font> to imply function templating.</div><div class=3D""><br class=3D""><=
/div><div class=3D""><font face=3D"Courier" class=3D"">decltype(auto) bind5=
( auto [&amp;]f ) {</font></div><div class=3D""><font face=3D"Courier" clas=
s=3D"">&nbsp; &nbsp; return f( 5 ); // Evaluate the argument expression her=
e.</font></div><div class=3D""><font face=3D"Courier" class=3D"">}</font></=
div><div class=3D""><br class=3D""></div><div class=3D"">Deducing class tem=
plate parameters from an initializer (i.e. parameter) could also help to de=
cide exactly what the wrapper is, allowing e.g. implicit conversion of the =
overloaded name to <font face=3D"Courier" class=3D"">std::function</font>&n=
bsp;when the receiver isn=E2=80=99t a template.</div><div class=3D""><br cl=
ass=3D""></div><div class=3D"">Sorry to be vague, but my personal suspicion=
 is that the best solution lies in the intersection of these several specul=
ative solution spaces.</div><div class=3D""><br class=3D""></div></body></h=
tml>

<p></p>

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

--Apple-Mail=_1F082AA6-39C1-4266-A7AD-1AECE78C8035--

.

On 2015-09-10 00:16, Germ=C3=A1n Diago wrote:
>     void f();
>     void f(int, float);
>     void f(int);
>=20
>     auto bound_f =3D bind (static_cast<void (*)(int, float)>(f),=20
> std::placeholders::_1, 3.8f);

Less of an improvement than your macro, but it might be cool to see
these standardized (especially if a better solution is not forthcoming):

    template<class... Args, class T, class R>
    auto overload(R (T::*m)(Args...)) -> decltype(m)
    { return m; }

    template<class T, class R>
    auto overload(R (T::*m)(void)) -> decltype(m)
    { return m; }

On the plus side, not a macro, and resolves to the desired overload
directly rather than adding an indirection through a templated lambda
(even if the compiler is able to optimize that away, though I don't know
that I would count on it being able to do so).

A better solution would be nice, though it could not be effective in all
situations.

I originally wanted the above for new-style Qt signal/slot connections,
which take two function pointers and validate that the argument lists
are compatible. There exist pathological cases for this that cannot be
solved fully automatically. For example:

  class Foo
  {
  signals:
    void noise(int);
    void noise(float);
  };

  class Bar
  {
  public slots:
    void listen(int);
    void listen(float);
  };

  connect(foo, &Foo::noise, bar, &Bar::listen);

The above is irresolvably ambiguous without additional information,
because either noise(int) + listen(int) or noise(float) + listen(float)
would be acceptable. (This is where the above 'overload<...>' is most
useful.)

Here's a silly notion: what if we allowed <>'s after any overloaded
function to select a particular overload? IOW:

  connect(foo, &Foo::noise<int>, bar, &Bar::listen<int>);

Still not as "perfect" as automatic resolution, but at least minimal
typing...

--=20
Matthew

--=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_472_322957566.1441942147695
Content-Type: multipart/alternative;
 boundary="----=_Part_473_1713470962.1441942147696"

------=_Part_473_1713470962.1441942147696
Content-Type: text/plain; charset=UTF-8

Less of an improvement than your macro, but it might be cool to see

> these standardized (especially if a better solution is not forthcoming):
>
>     template<class... Args, class T, class R>
>     auto overload(R (T::*m)(Args...)) -> decltype(m)
>     { return m; }
>
>     template<class T, class R>
>     auto overload(R (T::*m)(void)) -> decltype(m)
>     { return m; }
>

Well, it is better than current status, but why not go directly for a full
solution?


> On the plus side, not a macro, and resolves to the desired overload
> directly rather than adding an indirection through a templated lambda
> (even if the compiler is able to optimize that away, though I don't know
> that I would count on it being able to do so).
>

Taking into account that a lambda is declared inline, with current compiler
inliners,
I am pretty sure it is very easy to eliminate the overhead of the lambdas.


>
> The above is irresolvably ambiguous without additional information,
> because either noise(int) + listen(int) or noise(float) + listen(float)
> would be acceptable. (This is where the above 'overload<...>' is most
> useful.)
>

Well, actually my solution does not choose one function at the time of
connection,
at that time you would pass an overloaded function object.


> Here's a silly notion: what if we allowed <>'s after any overloaded
> function to select a particular overload? IOW:
>
>   connect(foo, &Foo::noise<int>, bar, &Bar::listen<int>);
>

I think this makes the pointer to member to look like a template, when in
fact it is not.
So I would choose something else.



--

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

<div dir=3D"ltr">Less of an improvement than your macro, but it might be co=
ol to see
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">these standardized (especi=
ally if a better solution is not forthcoming):
<br>
<br>=C2=A0 =C2=A0 template&lt;class... Args, class T, class R&gt;
<br>=C2=A0 =C2=A0 auto overload(R (T::*m)(Args...)) -&gt; decltype(m)
<br>=C2=A0 =C2=A0 { return m; }
<br>
<br>=C2=A0 =C2=A0 template&lt;class T, class R&gt;
<br>=C2=A0 =C2=A0 auto overload(R (T::*m)(void)) -&gt; decltype(m)
<br>=C2=A0 =C2=A0 { return m; }
<br></blockquote><div><br>Well, it is better than current status, but why n=
ot go directly for a full solution?<br>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">On the plus side, not a macro, and resolves to the=
 desired overload
<br>directly rather than adding an indirection through a templated lambda
<br>(even if the compiler is able to optimize that away, though I don&#39;t=
 know
<br>that I would count on it being able to do so).
<br></blockquote><div><br>Taking into account that a lambda is declared inl=
ine, with current compiler inliners,<br>I am pretty sure it is very easy to=
 eliminate the overhead of the lambdas.<br>=C2=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><br>The above is irresolvably ambiguous withou=
t additional information,
<br>because either noise(int) + listen(int) or noise(float) + listen(float)
<br>would be acceptable. (This is where the above &#39;overload&lt;...&gt;&=
#39; is most
<br>useful.)
<br></blockquote><div><br>Well, actually my solution does not choose one fu=
nction at the time of connection,<br>at that time you would pass an overloa=
ded function object.<br>=C2=A0<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;">Here&#39;s a silly notion: what if we allowed &lt;&gt;&#39;s afte=
r any overloaded
<br>function to select a particular overload? IOW:
<br>
<br>=C2=A0 connect(foo, &amp;Foo::noise&lt;int&gt;, bar, &amp;Bar::listen&l=
t;int&gt;);
<br></blockquote><div><br>I think this makes the pointer to member to look =
like a template, when in fact it is not.<br>So I would choose something els=
e.<br>=C2=A0<br></div><div>=C2=A0</div></div>

<p></p>

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

------=_Part_473_1713470962.1441942147696--
------=_Part_472_322957566.1441942147695--

.

------=_Part_749_64981022.1441959387347
Content-Type: multipart/alternative;
 boundary="----=_Part_750_1016620126.1441959387348"

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

On Wednesday, September 9, 2015 at 9:16:28 PM UTC-7, Germ=C3=A1n Diago wrot=
e:
>
> Hello everyone,
>
> A usability problem I found and it is quite annoying and could show in=20
> many scenarios,
> and potentially in generic scenarios, is the following one:
>
>
>     void f();
>     void f(int, float);
>     void f(int);
>
>
>     auto bound_f =3D bind(f, std::placeholders::_1, 3.8f); //Ambigous cal=
l
> =20
> Instead we must do this, which is annoying, but also advanced for=20
> non-expert users (usability problem):
>
>     auto bound_f =3D bind (static_cast<void (*)(int, float)>(f),=20
> std::placeholders::_1, 3.8f);
>

An alternative in C++14 is

    auto bound_f =3D [](auto x, ...){ return f(x, 3.8f); };

and then if you don't actually need the "..." part, you could drop it,=20
which would make your code read more cleanly.

    auto bound_f =3D [](auto x){ return f(x, 3.8f); };

I have thought it would be nice to have some sort of macro like

    #define OVERLOAD_SET(f) [](auto&&... args) { return=20
f(std::forward<decltype(args)>(args)...); }

but I've never actually found myself *needing* it in practice, yet.

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

<div dir=3D"ltr">On Wednesday, September 9, 2015 at 9:16:28 PM UTC-7, Germ=
=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello everyone,<br><br>A usability problem I found and it is quite=
 annoying and could show in many scenarios,<br>and potentially in generic s=
cenarios, is the following one:<br><br><br>=C2=A0=C2=A0=C2=A0 void f();<br>=
=C2=A0=C2=A0=C2=A0 void f(int, float);<br>=C2=A0=C2=A0=C2=A0 void f(int);<b=
r><br><br>=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind(f, std::placeholders::_1=
, 3.8f); //Ambigous call<br>=C2=A0<br>Instead we must do this, which is ann=
oying, but also advanced for non-expert users (usability problem):<br><br>=
=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind (static_cast&lt;void (*)(int, floa=
t)&gt;(f), std::placeholders::_1, 3.8f);<br></div></blockquote><div><br></d=
iv><div>An alternative in C++14 is</div><div><br></div><div>=C2=A0 =C2=A0 a=
uto bound_f =3D [](auto x, ...){ return f(x, 3.8f); };</div><div><br></div>=
<div>and then if you don&#39;t actually need the &quot;...&quot; part, you =
could drop it, which would make your code read more cleanly.</div><div><br>=
</div><div><div>=C2=A0 =C2=A0 auto bound_f =3D [](auto x){ return f(x, 3.8f=
); };</div></div><div><br></div><div>I have thought it would be nice to hav=
e some sort of macro like</div><div><br></div><div>=C2=A0 =C2=A0 #define OV=
ERLOAD_SET(f) [](auto&amp;&amp;... args) { return f(std::forward&lt;decltyp=
e(args)&gt;(args)...); }</div><div><br></div><div>but I&#39;ve never actual=
ly found myself *needing* it in practice, yet.</div></div>

<p></p>

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

------=_Part_750_1016620126.1441959387348--
------=_Part_749_64981022.1441959387347--

.

On 2015-09-10 23:29, german.diago@hubblehome.com wrote:
>> Less of an improvement than your macro, but it might be cool to see
>> [snipped]
>>
>> On the plus side, not a macro, and resolves to the desired overload
>> directly rather than adding an indirection through a templated lambda
>> (even if the compiler is able to optimize that away, though I don't know
>> that I would count on it being able to do so).
>
> Taking into account that a lambda is declared inline, with current
> compilerinliners, I am pretty sure it is very easy to eliminate the
> overhead of the lambdas.

Even in a case like this?

  void foo(void (*)(int));
  void foo(std::function<void (int)>);
  foo(overloaded(bar));

To be equally as efficient, the above would have to resolve to a call of
'void foo(void (*)(int))' with '&bar' (proper overload selected) as the
parameter. This happens with my helper function. I'm less sure it would
happen, or even if it legally *can* happen, with your lambda wrapper.

>> The above is irresolvably ambiguous without additional information,
>> because either noise(int) + listen(int) or noise(float) + listen(float)
>> would be acceptable. (This is where the above 'overload<...>' is most
>> useful.)
>
> Well, actually my solution does not choose one function at the time of
> connection,
> at that time you would pass an overloaded function object.

Well, yes, but I suppose my point is that your solution is not usable
for this case. Signals/slots *must* be fully resolved at call time (the
signal, at least). Also, I'm not sure if Qt's parameter matching would
work with templated lambdas.

--
Matthew

--

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

.