220 20470 <55F8A5FA.5070004@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: D0051- C++ generic overload function Date: Wed, 16 Sep 2015 01:12:58 +0200 Lines: 169 Approved: news@gmane.org Message-ID: <55F8A5FA.5070004@wanadoo.fr> References: <55F8771B.1090108@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1442358798 20890 80.91.229.3 (15 Sep 2015 23:13:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 23:13:18 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB66L4KXQKGQER3MQBOQ@isocpp.org Wed Sep 16 01:13:04 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f72.google.com ([209.85.215.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZbzPJ-0002Zl-E4 for gclcip-std-proposals@m.gmane.org; Wed, 16 Sep 2015 01:13:01 +0200 Original-Received: by lamp12 with SMTP id p12sf66196750lam.2 for ; Tue, 15 Sep 2015 16:13:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=5vhWXjTIqXPdwWNRmPJt/b9/7/leL/sIiuVxTghALTY=; b=Qg2uTCXEvmwRFM0RFuCGqAIN89fY4ynW0uK2Q14TiE1Jj1C0HQcncg31t3EKPnILTm imL6pMuOdpnSlKZTZWN2bRV5zTShp+92C8Jq3L13UWLKMNytPqj0FeTkM5ONay/k0cd3 PMAGetFbccIvP21POaNgGsoUV9KjG9S/4numywge0SgRhejaqtFJoG+BXWv3BOJa1adC 4bo8EkC/pJJWU86Ulcu/micV8n4zF5MRV5TCO/ktYdQbKCc+9oHGvTQPM6qd4mJDrfwR ixbZlj3ArPvQDw3UK6o2ZlxwsSLawqJ+qg0PhbKWADxRuEr X-Gm-Message-State: ALoCoQmfPrx7/N+44UqFjIE0UL7cDLqV0ci5inxAo8idAFE314k3Uh+/QLE5RjpO1LMMOgzfyIjZ X-Received: by 10.180.105.98 with SMTP id gl2mr1317292wib.0.1442358780943; Tue, 15 Sep 2015 16:13:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.103.8 with SMTP id fs8ls1197814wib.25.gmail; Tue, 15 Sep 2015 16:12:59 -0700 (PDT) X-Received: by 10.180.37.76 with SMTP id w12mr12608151wij.0.1442358779356; Tue, 15 Sep 2015 16:12:59 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr. [80.12.242.125]) by mx.google.com with ESMTPS id ju9si2252490wid.47.2015.09.15.16.12.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Sep 2015 16:12:59 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.125; Original-Received: from new-host.home ([2.11.255.5]) by mwinf5d26 with ME id HbCy1r00607lkcJ03bCyaV; Wed, 16 Sep 2015 01:12:59 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Wed, 16 Sep 2015 01:12:59 +0200 X-ME-IP: 2.11.255.5 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:20470 Archived-At: Le 15/09/15 23:38, 'Matt Calabrese' via ISO C++ Standard - Future=20 Proposals a =C3=A9crit : > On Tue, Sep 15, 2015 at 12:52 PM, Vicente J. Botet Escriba < > vicente.botet@wanadoo.fr> wrote: > >> Hi, >> >> [1] proposes two functions that allow to overload lambdas and functio= n >> objects, but also member and non-member functions. >> >> * overload selects the best overload using C++ overload resolution and >> * first_overload selects the first overload using C++ overload resolutio= n. >> >> Any feedback is welcome. >> >> Vicente Botet >> >> [1] >> https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.= pdf > > +1 > > I'm glad this is being proposed. Something to consider: if all of the > proposed invocation traits components end up in the language at some poin= t, > I believe that it also may be possible to implement a version of "overloa= d" > that does not copy/move any of the passed-in function arguments, but > instead holds them by reference, or at least that was my belief when I > originally looked through invocation traits (I never actually went throug= h > and attempted it, so it it might not actually be enough -- I only suspect= ed > that it may be). The principle behind using invocation traits there is th= at > you'd make the value-based version that you already have, but in a purely > unevaluated context, and then use invocation traits facilities to determi= ne > exactly which operator() overload was picked (this facility was a part of > the proposal though I'm not sure that this part will be in C++17). I like the invocation traits proposal and I hope that it would be used=20 by a lot of forwarding functions. Could someone confirm if it has been=20 adopted for the next C++17 standard? I don't see to which function do you want to apply the invocation=20 traits. IIUC, you want an overload function having the overloaded=20 functions passed by reference, isn't it? Are you suggesting to apply these traits to the overloaded functions to=20 take care the references parameters? > With > that information, you should then be able to call the appropriate functio= n > in the "tie_overloads" implementation without ever having copied any of t= he > underlying function objects. Again, I never fully examined the possibilit= y, > I only suspected that invocation traits would allow this to be implemente= d. > If so, it might be sufficient rationale to also push all of the facilitie= s > in the invocation traits proposal into the language, or otherwise > introduce similar facilities that would actually make such a > "tie_overloads" function possible to implement. Please, could you elaborate on this tie_overload, I'm a little lost,=20 some usage examples, ... > > Regarding your open points: > > 1) Should the callable be passed by value? In my opinion, no it should no= t, > and this is the growing trend in other proposals as well. To be franc, I have not think at all at the possibility to pass them by=20 reference. I was hoping that nobody was requesting them. I'll see what=20 can be done. > > 2) A better name for the proposed function? I would personally suggest > "overloads" as opposed to "overload." I understand that "overload" is > intended to be a verb here, which is fine, I just personally consider tha= t > thinking of it as a noun is convenient such that you can have something > like "tie_overloads" or "forward_as_overloads" to do the other things I > mentioned earlier in this reply. If the name is "overload," I don't see a= n > obvious way to be consistent (I may just not be being creative enough). A= t > the very least, even if there is no "tie" based version of the overload > templates to be initially proposed, it seems to me to make sense to be > aware that one may come at some point in a future standard. > 3) Do we want to expose the result type of these function? In a world wit= h > decltype this seems unnecessary as proposed. I do, however, think that it > might be important if "overload" has an optional syntax: > > ////////// > overload([](a) {/**/}, [](b) {/**/}) > ////////// Yeah, I have implemented this already to cover exactly this use case:=20 the users wants a specific return type. > The idea of the above is that when the overload is invoked, the return ty= pe > of the wrapped function call is always "desired_return_type," converting > the result if necessary (and producing an error if there is no conversion= ). > Internally this could be exposed as nested typedef. The idea is that this > can be useful when using "overload" as an argument to something like > visitation of a variant and can even improve compile-times if visitation > would otherwise try to deduce the return type by minimizing template > instantiations. An example of what I mean using boost apply_visitor as an > example: > > ////////// > auto result > =3D apply_visitor(overload([](a const& arg1, b const& arg2) {/**/= } > /*...*/) , variant_1, variant_2); > ////////// > > To understand why this is helpful, consider what happens if you didn't > explicitly specify "int". Internal to the implementation, in order to > deduce the result of the overall visitation (assuming we want to do this = at > all), it would have to instantiate all of the possibilities and use > something like common_type, or possibly produce a hard error in the case > that the types do not match. By, instead, explicitly specifying the retur= n > type for overloads, apply_visitor would be able to see that result type a= nd > use it without having to do some kind of complicated deduction. How can apply_visitor take advantage of a function object that has a=20 unique return type for all the overloads? Do you pretend that=20 apply_visitor works only with function objects that return a unique=20 return types for all the overloads? I hope not. Or that it can be able=20 to detect if the function object has a nested typedef and it can avoid=20 thus the whole deduction? Do you believe that this would reduce=20 consequently the compilation time? Is this the single argument? > You could > (and likely should) also be able to explicitly specify the result type > directly with apply_visitor by doing "apply_visitor," though having = it > optionally done directly with "overloads" makes this more generally usefu= l > in context other than variant visitation as well (for instance, algorithm= s > that operate on elements of tuples). > > Much of this rationale is somewhat predicated on us getting a proper > variant in the language, but that rationale is still useful given that su= ch > libraries exist in the real world already and it would be great if > "overload" had such use-cases explicitly in mind, regardless. > Point taken. I'll add this overload to overload;-) Vicente --=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/. .