220 20378 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Germ=C3=A1n_Diago?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Usability improvement: Unambiguously resolve overloaded functions when passed as function parameters Date: Wed, 9 Sep 2015 21:16:28 -0700 (PDT) Lines: 124 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4641_1457003317.1441858588725" X-Trace: ger.gmane.org 1441858611 7834 80.91.229.3 (10 Sep 2015 04:16:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 04:16:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDC2VXM4YYDRBHMIYSXQKGQEM3DG5UI@isocpp.org Thu Sep 10 06:16:33 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZtHj-0000Yc-K7 for gclcip-std-proposals@m.gmane.org; Thu, 10 Sep 2015 06:16:31 +0200 Original-Received: by oibi136 with SMTP id i136sf47357953oib.3 for ; Wed, 09 Sep 2015 21:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BBTggmN75vqGzGInDCBGDxeqod8JeNEnTiFDVQdfFDs=; b=mrsVyW5PZHwEhwFymsrMVxSS8+I5HBtO3pCYDyj98jutCgp5+LCvoMMdnFoGqm59aZ xL0nZ2nB9tY472sF3bOhMZQQ+W0W/gj4OH2UZ9qE0FBow+rlZXZPqkWriqBYdiGjHQOz guozbgw6y9iMkrZo5u9DBOQ24ff5Dy8pZ3US+FO02u47j8zmf9NsqAaHWf93tgbAo2+k T6SLWtO3Lbb4ZPDrj3dXK020BcJnYLgc0GecMX2/+dzCwDd4alkwDHMiwdiE1y8nY9Wi UEgU0CKeXlNTTnGRNxXs9NmLheFgz1CNozv5S0H0vTPC+tyt0zVfWcHePq83/gfQGYOB 3+Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BBTggmN75vqGzGInDCBGDxeqod8JeNEnTiFDVQdfFDs=; b=j31nCao7yqFkhidVqFb9MgrHhfLhKkexxB4zEtb80+DyMudm3HM+eqp9J9qkmhzDmF eL2fP0IoMdr3oDnOpyi3rLX93VHdskVgOjo9gsrmIXU3Q3LIrGMY46PWo0Z9ulDIV9PJ BCssLtVXJSEF0c1xMTwCyOMEiXkt+DgGRTTgAC7TKnYDQc0cAQCVNWOqLvU+tGrmeINT UVg40AYNz1ZQxbZht7pMR7Pb6wSA8u8+GmcjRU3c9IBc8Wq9K380tbGLRgj8HhDIK7os Mxn2fXFLcB/CKjrKTjvrcE6OkwaXaeso104xhrc6i6Gv7QhIC3aaGQC69dtvh6hhTTlV duBQ== X-Gm-Message-State: ALoCoQm1KDuvPBKTg+fBN1OtPDdH40jLtN+q70nFbbHCraTb6z0FjqHCB1yHKEZ72aWqZ+npkAt9 X-Received: by 10.182.242.6 with SMTP id wm6mr32884249obc.50.1441858590603; Wed, 09 Sep 2015 21:16:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.33.149 with SMTP id h143ls400399ioh.42.gmail; Wed, 09 Sep 2015 21:16:29 -0700 (PDT) X-Received: by 10.50.1.97 with SMTP id 1mr7032igl.13.1441858589782; Wed, 09 Sep 2015 21:16:29 -0700 (PDT) X-Original-Sender: germandiago@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:20378 Archived-At: ------=_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(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(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 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
Hello everyone,

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


=C2=A0=C2=A0=C2=A0 void = f();
=C2=A0=C2=A0=C2=A0 void f(int, float);
=C2=A0=C2=A0=C2=A0 void f= (int);


=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind(f, std::placehol= ders::_1, 3.8f); //Ambigous call
=C2=A0
Instead we must do this, whic= h is annoying, but also advanced for non-expert users (usability problem):<= br>
=C2=A0=C2=A0=C2=A0 auto bound_f =3D bind (static_cast<void (*)(in= t, float)>(f), std::placeholders::_1, 3.8f);


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

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


Now I can do:
=C2=A0=C2=A0 auto bound_f =3D 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).

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

=C2= =A0=C2=A0 apply(overloaded(f), args); //Correct


Note that this o= verloaded trick can only be done through a macro. If you try to use a funct= ion called overloaded,
the deduced function is still ambiguous when pass= ed 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,<= br>propose that the function is chosen as-if wrapped in that lambda:
=C2=A0=C2=A0 apply(f, args); //as if called by apply(overloaded(f), args);= because f would be ambiguous.

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

Is there any inter= est in solving this problem?


--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_4642_1776152968.1441858588725-- ------=_Part_4641_1457003317.1441858588725-- .