Topic: Resolving overloaded functions unambiguosuly when
Author: "germandiago@gmail.com" <german.diago@hubblehome.com>
Date: Wed, 9 Sep 2015 20:27:41 -0700 (PDT)
Raw View
------=_Part_3004_789734734.1441855661534
Content-Type: multipart/alternative;
boundary="----=_Part_3005_984636046.1441855661535"
------=_Part_3005_984636046.1441855661535
Content-Type: text/plain; charset=UTF-8
Hello everyone,
I am finding increasingly annoying to manage code like this:
void f(int);
void f(float);
void f(int, int);
In functions such as std::bind, std::experimental::apply and std::invoke,
you have to disambiguate through a cast:
auto new_f = std::bind(static_cast<void (*)(int)>(&f),
std::placeholders::_1);
So I did something like this:
#define overloaded(f) [](auto &&... args) { return
f(std::forward<decltype(args)>(args)...); }
auto new_f_ovload = std::bind(overloaded(f), std::placeholders::_1);
//works!
tuple<int, int> args{7, 5};
apply(overloaded(f), args); //works!
bind(overloaded(f), 5, std::placeholders::_1); //works!
There is any chance that the language could be modified so that (would it
break anything?), with the as-if rule:
When an overloaded function is passed as a function parameter (maybe other
places?), if the
overload resolution would result in an ambiguous call, then, the function
is passed as-if wrapped by a lambda:
apply(f, a, b); //translated as-if it was apply([](auto &&... args) {
return f(forward<decltype(args)>(args...)); }, a, b);
Would this make any sense? Generic code tends to be quite overloaded and
casting around is quite inconvenient.
This would eliminate a big usability problem.
Regards
--
---
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_3005_984636046.1441855661535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone, <br><br><br>I am finding increasingly anno=
ying to manage code like this:<br><br>=C2=A0=C2=A0=C2=A0 void f(int);<br>=
=C2=A0=C2=A0=C2=A0 void f(float);<br>=C2=A0=C2=A0=C2=A0 void f(int, int);<b=
r><br>In functions such as std::bind, std::experimental::apply and std::inv=
oke, you have to disambiguate through a cast:<br><br>=C2=A0=C2=A0=C2=A0 aut=
o new_f =3D std::bind(static_cast<void (*)(int)>(&f), std::placeh=
olders::_1);<br><br><br>So I did something like this:<br><br>=C2=A0=C2=A0=
=C2=A0 #define overloaded(f) [](auto &&... args) { return f(std::fo=
rward<decltype(args)>(args)...); }<br><br><br>=C2=A0=C2=A0=C2=A0 auto=
new_f_ovload =3D std::bind(overloaded(f), std::placeholders::_1); //works!=
<br><br>=C2=A0=C2=A0=C2=A0 tuple<int, int> args{7, 5};<br>=C2=A0=C2=
=A0=C2=A0 apply(overloaded(f), args); //works!<br>=C2=A0=C2=A0=C2=A0 bind(o=
verloaded(f), 5, std::placeholders::_1); //works!<br><br>=C2=A0There is any=
chance that the language could be modified so that (would it break anythin=
g?), with the as-if rule:<br><br>When an overloaded function is passed as a=
function parameter (maybe other places?), if the <br>overload resolution w=
ould result in an ambiguous call, then, the function is passed as-if wrappe=
d by a lambda:<br><br>apply(f, a, b); //translated as-if it was apply([](au=
to &&... args) { return f(forward<decltype(args)>(args...)); =
}, a, b);<br><br>Would this make any sense? Generic code tends to be quite =
overloaded and casting around is quite inconvenient.<br>This would eliminat=
e a big usability problem.<br><br>Regards<br><br>=C2=A0=C2=A0=C2=A0 <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" 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_3005_984636046.1441855661535--
------=_Part_3004_789734734.1441855661534--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 15 Sep 2015 08:51:02 +0800
Raw View
--Apple-Mail=_AECB67C6-5142-4DC2-BB04-67DC9993F719
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Why did you not continue the thread on the same topic you started last week=
? (Usability improvement: Unambiguously resolve overloaded functions when p=
assed as function parameters)
> On 2015=E2=80=9309=E2=80=9310, at 11:27 AM, germandiago@gmail.com <german=
..diago@hubblehome.com> wrote:
>=20
> I am finding increasingly annoying to manage code like this:
>=20
> void f(int);
> void f(float);
> void f(int, int);
Why not put those signatures inside a function object?
> In functions such as std::bind, std::experimental::apply and std::invoke,=
you have to disambiguate through a cast:
>=20
> auto new_f =3D std::bind(static_cast<void (*)(int)>(&f), std::placeho=
lders::_1);
All three of those facilities also allow an explicit template argument, whi=
ch saves you from writing =E2=80=9Cstatic_cast.=E2=80=9D
> There is any chance that the language could be modified so that (would it=
break anything?), with the as-if rule:
>=20
> When an overloaded function is passed as a function parameter (maybe othe=
r places?), if the=20
> overload resolution would result in an ambiguous call, then, the function=
is passed as-if wrapped by a lambda:
Now the deduced type depends on the number of overloads on the name. Seems =
very sneaky and likely to fail the ODR.
I think this feature would work better with some opt-in syntax like [] eith=
er in the argument or the parameter. (As mentioned in the last thread, the =
parameter seems preferable.)
> Would this make any sense? Generic code tends to be quite overloaded and =
casting around is quite inconvenient.
> This would eliminate a big usability problem.
Personally I try to contain the overloading in functor classes anyway. If y=
ou use the overloaded(f) macro to define dispatching classes in the headers=
, then users don=E2=80=99t need to worry about the call sites =E2=80=94 as =
long as the dispatcher can find the functions by ADL.=20
Be careful not to have the macro defined when including any third-party hea=
ders, because overloaded is a perfectly common identifier for anyone to use=
..
--=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=_AECB67C6-5142-4DC2-BB04-67DC9993F719
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""><div class=3D"">Wh=
y did you not continue the thread on the same topic you started last week? =
(<span style=3D"font-family: 'Helvetica Neue';" class=3D"">Usability improv=
ement: Unambiguously resolve overloaded functions when passed as function p=
arameters)</span></div><div class=3D""><span style=3D"font-family: 'Helveti=
ca Neue';" class=3D""><br class=3D""></span></div><div class=3D""><span sty=
le=3D"font-family: 'Helvetica Neue';" class=3D""><br class=3D""></span></di=
v><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=
=9309=E2=80=9310, at 11:27 AM, <a href=3D"mailto:germandiago@gmail.com" cla=
ss=3D"">germandiago@gmail.com</a> <<a href=3D"mailto:german.diago@hubble=
home.com" class=3D"">german.diago@hubblehome.com</a>> wrote:</div><br cl=
ass=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D=
"">I am finding increasingly annoying to manage code like this:<br class=3D=
""><br class=3D""> void f(int);<br class=3D"">  =
; void f(float);<br class=3D""> void f(int, int);<b=
r class=3D""></div></div></blockquote><div><br class=3D""></div><div>Why no=
t put those signatures inside a function object?</div><br class=3D""><block=
quote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">=
In functions such as std::bind, std::experimental::apply and std::invoke, y=
ou have to disambiguate through a cast:<br class=3D""><br class=3D""> =
auto new_f =3D std::bind(static_cast<void (*)(int)>(&=
;f), std::placeholders::_1);<br class=3D""></div></div></blockquote><div><b=
r class=3D""></div><div>All three of those facilities also allow an explici=
t template argument, which saves you from writing =E2=80=9C<font face=3D"Co=
urier" class=3D"">static_cast</font>.=E2=80=9D</div><br class=3D""><blockqu=
ote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">Th=
ere is any chance that the language could be modified so that (would it bre=
ak anything?), with the as-if rule:<br class=3D""></div></div></blockquote>=
<div><blockquote type=3D"cite" class=3D""><br class=3D""></blockquote></div=
><blockquote type=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" clas=
s=3D"">When an overloaded function is passed as a function parameter (maybe=
other places?), if the <br class=3D"">overload resolution would result in =
an ambiguous call, then, the function is passed as-if wrapped by a lambda:<=
br class=3D""></div></div></blockquote><div><br class=3D""></div><div>Now t=
he deduced type depends on the number of overloads on the name. Seems very =
sneaky and likely to fail the ODR.</div><div class=3D""><br class=3D""></di=
v><div class=3D"">I think this feature would work better with some opt-in s=
yntax like <font face=3D"Courier" class=3D"">[]</font> either in the argume=
nt or the parameter. (As mentioned in the last thread, the parameter seems =
preferable.)</div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D"">Would this make any sense? Generic c=
ode tends to be quite overloaded and casting around is quite inconvenient.<=
br class=3D"">This would eliminate a big usability problem.<br class=3D""><=
/div></div></blockquote></div><br class=3D""><div class=3D"">Personally I t=
ry to contain the overloading in functor classes anyway. If you use the <fo=
nt face=3D"Courier" class=3D"">overloaded(f)</font> macro to define dispatc=
hing classes in the headers, then users don=E2=80=99t need to worry about t=
he call sites =E2=80=94 as long as the dispatcher can find the functions by=
ADL. </div><div class=3D""><br class=3D""></div><div class=3D"">Be ca=
reful not to have the macro defined when including any third-party headers,=
because <font face=3D"Courier" class=3D"">overloaded</font> is a perfectly=
common identifier for anyone to use.</div><div class=3D""><br class=3D""><=
/div></body></html>
<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 <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=_AECB67C6-5142-4DC2-BB04-67DC9993F719--
.
Author: german.diago@hubblehome.com
Date: Mon, 14 Sep 2015 21:15:43 -0700 (PDT)
Raw View
------=_Part_441_749281319.1442290543561
Content-Type: multipart/alternative;
boundary="----=_Part_442_914302160.1442290543562"
------=_Part_442_914302160.1442290543562
Content-Type: text/plain; charset=UTF-8
Why did you not continue the thread on the same topic you started last
> week? (Usability improvement: Unambiguously resolve overloaded functions
> when passed as function parameters)
>
I think I posted twice by accident. The first time I posted it did not
show, now it appears. Sorry.
>
>
--
---
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_442_914302160.1442290543562
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div style=3D"word-wrap:break-word"><div>Why did you not continue the thread=
on the same topic you started last week? (<span style=3D"font-family:'=
Helvetica Neue'">Usability improvement: Unambiguously resolve overloade=
d functions when passed as function parameters)</span></div></div></blockqu=
ote><div><br>I think I posted twice by accident. The first time I posted it=
did not show, now it appears. Sorry.<br>=C2=A0<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 style=3D"word-wrap:break-word"><br></div><=
/blockquote></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 <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_442_914302160.1442290543562--
------=_Part_441_749281319.1442290543561--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 15 Sep 2015 09:34:43 -0400
Raw View
On 2015-09-14 20:51, David Krauss wrote:
>> On 2015=E2=80=9309=E2=80=9310, at 11:27 AM, germandiago@gmail.com wrote:
>>
>> I am finding increasingly annoying to manage code like this:
>>
>> void f(int);
>> void f(float);
>> void f(int, int);
>=20
> Why not put those signatures inside a function object?
Besides that doing so is extra effort, "unusual", and a work-around for
what can be seen as a defect in the language?
What if they're member functions? What if they come from an external
library, or otherwise are not readily changeable?
Personally, I can't say I've ever done this, nor ever seen it done.
--=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/.
.