220 20473 <55F94F03.3010409@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 13:14:11 +0200 Lines: 154 Approved: news@gmane.org Message-ID: <55F94F03.3010409@wanadoo.fr> References: <55F8771B.1090108@wanadoo.fr> <55F8A5FA.5070004@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 1442402064 11646 80.91.229.3 (16 Sep 2015 11:14:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 11:14:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBBM64WXQKGQEPSIKPFA@isocpp.org Wed Sep 16 13:14:16 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f199.google.com ([209.85.212.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZcAfH-0006hv-Ew for gclcip-std-proposals@m.gmane.org; Wed, 16 Sep 2015 13:14:15 +0200 Original-Received: by wicmn1 with SMTP id mn1sf19918337wic.1 for ; Wed, 16 Sep 2015 04:14:15 -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=JHMMM6kFbljjLPxPseoffmhZMPqlvU2yN6/s7QIGb9s=; b=mWvE1qf3w3A3V0UT8a3ScMcoUnM7vEt+1s4qxPRv6qMHho6MxKY5O+gzQ/h3a5I08N qUKtc9traA1pYwQn1j/XOWJG158YrN5LRruF/CB3ct4Mjyvvkir4faJQi80aJOJp/S+n LVxqD+UMBtr86WmpBXsXUMKpSYED4pSaBF1bF73PvOM5QahrgjatYLbQr0WzSOdZa6zL 5nocsV+TjjLY2yR4k4pTZuTtb9ThonzZlWUMgycdi5x/jtCD6hBlhOb/wYabYT1hvWKG LaYYRsrq9+5PyU03t4ebIJkBCTSHALoQglMX98K0lnjPmOB X-Gm-Message-State: ALoCoQk8EJMPE97TLkLPg9snaxcLthWjjkI6mugG33+ODsWSBcwZJNozzCoe1JZKB16iK4L00Sx0 X-Received: by 10.112.26.212 with SMTP id n20mr5357836lbg.2.1442402055043; Wed, 16 Sep 2015 04:14:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.106.5 with SMTP id gq5ls1317262wib.31.gmail; Wed, 16 Sep 2015 04:14:12 -0700 (PDT) X-Received: by 10.194.58.71 with SMTP id o7mr52024729wjq.82.1442402052948; Wed, 16 Sep 2015 04:14:12 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr. [80.12.242.127]) by mx.google.com with ESMTPS id d3si5638086wie.23.2015.09.16.04.14.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 16 Sep 2015 04:14:12 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.127 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.127; Original-Received: from new-host.home ([2.11.255.5]) by mwinf5d61 with ME id HnEB1r00G07lkcJ03nECoR; Wed, 16 Sep 2015 13:14:12 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Wed, 16 Sep 2015 13:14:12 +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.127 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:20473 Archived-At: Le 16/09/15 01:50, 'Matt Calabrese' via ISO C++ Standard - Future=20 Proposals a =C3=A9crit : > On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba < > vicente.botet@wanadoo.fr> wrote: >> I like the invocation traits proposal and I hope that it would be used b= y >> a lot of forwarding functions. Could someone confirm if it has been adop= ted >> for the next C++17 standard? >> I don't see to which function do you want to apply the invocation traits= .. >> IIUC, you want an overload function having the overloaded functions pass= ed >> by reference, isn't it? >> Are you suggesting to apply these traits to the overloaded functions to >> take care the references parameters? Thanks for the pass by reference example. However I don't see yet where you= would like to use the invocation traits. Is on the operator() defined in t= he resulting function object? > =20 > > For a usage example: > > ////////// > struct function_with_state { > void operator ()(int arg) { invoked =3D true; } > bool invoked =3D false; > }; > > function_with_state foo; > > apply_visitor(forward_as_overloads(foo, [](a arg) { /**/ }), > variant_instance); > > // You can now check foo.invoked; > bool invoked =3D foo.invoked; > ////////// > > This is an obviously contrived example, but the underlying idea is that y= ou > want to be able to examine or continue modifying state that was mutated b= y > the visitation. Standard library algorithms like std::for_each effectivel= y > accomplish this by returning the function object, which also might be > feasible if there were a form of apply_visitor that yielded the passed-in > function object in addition to or in place of the result of the function > object's invocation. Other reasons to prefer "tie_overloads" or > "forward_as_overloads" would be when even a move is costly or simply does > not exist. > > The closest equivalent to my above example using only "overload" that I c= an > think of off-hand would be something like: > > ////////// > struct function_with_state { > void operator ()(int arg) { invoked =3D true; } > bool invoked =3D false; > }; > > auto fun =3D overloads(function_with_state(), [](a arg) { /**/ }; > apply_visitor(std::ref(fun), variant_instance); I will add the possibility to pass a reference_wrapper to the match=20 proposal (See D0050) > // Assumes some way to access one of the contained "overload" functions. > // Here I just use std::get with the type, but hypothetically it could be > done > // with std::get and an index, or some other way entirely. Obviously this > // would need to be proposed. > bool invoked =3D std::get(fun).invoked; > ////////// So you want that the result of overload behaves like a product type. I=20 will add this to the list of further work. > On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba < > vicente.botet@wanadoo.fr> wrote: > >> Yeah, I have implemented this already to cover exactly this use case: th= e >> users wants a specific return type. > > Great! I think this would be a good addition to a complete proposal. > > On Tue, Sep 15, 2015 at 4:12 PM, Vicente J. Botet Escriba < > vicente.botet@wanadoo.fr> wrote: > >> How can apply_visitor take advantage of a function object that has a >> unique return type for all the overloads? Do you pretend that apply_visi= tor >> works only with function objects that return a unique return types for a= ll >> the overloads? I hope not. Or that it can be able to detect if the funct= ion >> object has a nested typedef and it can avoid thus the whole deduction? D= o >> you believe that this would reduce consequently the compilation time? Is >> this the single argument? > > I suggest the following: > > 1) If apply_visitor is given an explicit result type, use that. > 2) If apply_visitor is NOT given an explicit result type, use the explici= t > result type of the function object if one exists. OK, up to this point we don't need to calculate the Cartesian product of=20 all the sum type alternatives to have the type of the possible=20 invocations. I will add this to the match proposal and check the=20 compilation times. > 3) If neither apply_visitor nor the function object have an explicit resu= lt > type, but all of the invocations would have the same result type, use tha= t. This would need to calculate the Cartesian product only lazily, and stop=20 as soon as the types are not all the same. > 4) If none of the above are true, then we have a few final options: > a) Produce a compile time error > b) Return void or some stateless type > c) Try to do some kind of common type deduction This would need to calculate the Cartesian product only lazily, and stop=20 as soon as there is no a common type. We could provide a meta-function that folds the Cartesian product of all=20 the sum type alternatives and applies a SFINAE friendly type=20 transformation. For 3) we need same::type and for 4) c) we need=20 common_type::type. I will add 3) and 4) in Further work section to the match proposal until=20 I implement them. > To be optimal with compile-times, which is something that becomes a serio= us > consideration with variants having many states and/or doing n-ary > visitation for n > 1, users would prefer option 1 or option 2, since > otherwise the implied checking, especially if common type deduction is at > play, could be considerable. > Got it. Vicente P.S. Please see the update on the same address=20 https://github.com/viboes/tags/blob/master/doc/proposals/overload/D0051.pdf --=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/. .