220 18770 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Thu, 25 Jun 2015 15:36:50 +0800 Lines: 138 Approved: news@gmane.org Message-ID: References: <59ED9069-2650-44E2-B00E-0E56ED37B83D@gmail.com> <4f0124c9-aa8e-4d40-b10e-7b3bee362398@isocpp.org> <5dcf242c-aef0-4d0b-b2f7-45273968cba9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244" X-Trace: ger.gmane.org 1435217842 23627 80.91.229.3 (25 Jun 2015 07:37:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 07:37:22 +0000 (UTC) Cc: std-proposals@isocpp.org To: Arthur O'Dwyer Original-X-From: std-proposals+bncBCW25A7E3QCRBHW7V2WAKGQENMQV4RI@isocpp.org Thu Jun 25 09:37:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z81ia-0002T3-Vu for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 09:37:05 +0200 Original-Received: by pdir4 with SMTP id r4sf80574283pdi.2 for ; Thu, 25 Jun 2015 00:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to: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=sKje00W+kAKqEPjmzexEwVeQ7sF026pfnxqh0LtBKSo=; b=jbQ3HriBfN9LQbXo4NiGqcxxQlKORk6VN3M0RsVD23BGemPd7PjnERqgAfbIrjWoE9 VErEge+gDIoxAHC1oe/XwgI3bo95or6AsZfy5Rbxdf4USCqjzAZhmbBjwqGkHnvZTqyu 9uu6rWDJ3aK4qNCNa3J1YVWGVTjuCdOyZLdqLBRvf9iYvL0KT7B6R1K3G83eY/bYD/u9 1QeCVORBP4gpqnijcR23sPjh6NTsr1fPszDiXbs20NMSTL1V6PdxqlUVVPFEwtx+Rfcq cGLGn2CLlcioyM/xVrIrx3FOBmw1FVsKVnuSTTE2TOqPajqTlhHXcJDxKY8/tRoicqIV LzQQ== X-Gm-Message-State: ALoCoQl3kgvcyE5OuSH5mkMN2G6DvWZGdSr9CuJte7dRBKL6k7Gl3wh4RH7vH9DKCgnymfFCRdQO X-Received: by 10.70.123.168 with SMTP id mb8mr57798163pdb.7.1435217823302; Thu, 25 Jun 2015 00:37:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.23.39 with SMTP id j7ls1861871igf.3.canary; Thu, 25 Jun 2015 00:37:02 -0700 (PDT) X-Received: by 10.69.10.196 with SMTP id ec4mr89043950pbd.69.1435217822472; Thu, 25 Jun 2015 00:37:02 -0700 (PDT) Original-Received: from nk11p04mm-asmtp002.mac.com (nk11p04mm-asmtp002.mac.com. [17.158.236.237]) by mx.google.com with ESMTPS id ps1si43765170pdb.215.2015.06.25.00.37.02 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 00:37:02 -0700 (PDT) Received-SPF: pass (google.com: domain of david_work@me.com designates 17.158.236.237 as permitted sender) client-ip=17.158.236.237; Original-Received: from [172.20.10.2] (unknown [121.54.44.90]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NQH00JPAP5E0N10@nk11p04mm-asmtp002.mac.com> for std-proposals@isocpp.org; Thu, 25 Jun 2015 07:36:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-06-25_03:2015-06-23,2015-06-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1506250130 In-reply-to: <5dcf242c-aef0-4d0b-b2f7-45273968cba9@isocpp.org> X-Mailer: Apple Mail (2.2098) X-Original-Sender: david_work@me.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of david_work@me.com designates 17.158.236.237 as permitted sender) smtp.mail=david_work@me.com; dmarc=pass (p=NONE dis=NONE) header.from=me.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:18770 Archived-At: --Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9306=E2=80=9325, at 3:03 PM, Arthur O'Dwyer wrote: >=20 > This is exactly N4159 "std::function and beyond", correct? Not =E2=80=9Cexactly,=E2=80=9D but pretty much. > N4159 strikes me as exactly the reasonable and sensible thing to do (both= to fix the thread-safety/const-correctness issue, and to enable std::funct= ion-izing of move-only lambdas); can anyone shed some light on its current = disposition? N4159 was accepted as a good to-do list. N4348 and N4543 are follow-ups. > David Krauss, as the author of N4543 (std::unique_function), do = you think it's in any way preferable to N4159 (std::function), a= s in, > - is there a good reason to reject N4159? > - if N4159 were adopted, would there still be a good reason to adopt N454= 3? Some cognitive dissonance here. How have I contradicted N4159? If you want to allow non-copyable targets, there are only two choices: 1. L= et std::function accept them and define its copy constructor to throw (or U= B), or 2. Create a new, non-copyable polymorphic wrapper. Looking at page 8 of N4159, it suggests the name std::movable_function for = what I called unique_function. It goes on to suggest a combined template st= d::basic_function with a bool non-type parameter. I left this as an impleme= ntation detail; I don=E2=80=99t think it=E2=80=99s a good interface. I don= =E2=80=99t see it analyzing alternative #1 at all. > P.S.: I just ran into this issue while attempting to write a Scheduler th= at manipulates Tasks, where a Task might be for example a lambda one of who= se captures is a non-copyable UniquePromise. My solution was to implement T= ask from scratch; but in a perfect world Task would have been a typedef for= std::function. That would be std::unique_function. Put an rvalue qualifier inside = if you like. See this summary from the documentation to my prototype library. LEWG in Urbana took a number of straw polls to refine the direction of N415= 9. They=E2=80=99re in the LEWG bugzilla but I can=E2=80=99t find the link r= ight now. --=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=_AF07809F-0245-48C1-BB15-A3290151F244 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2=80=9306= =E2=80=9325, at 3:03 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

This is= exactly N4159 "std::function and beyond", correct?

Not =E2=80=9Cexactly,=E2=80=9D but pretty m= uch.

N4159 strikes me as exactly the reasonable an= d sensible thing to do (both to fix the thread-safety/const-correctness iss= ue, and to enable std::function-izing of move-only lambdas); can anyone she= d some light on its current disposition?

N4159 was accepted as a good to-do list. N4348 and N45= 43 are follow-ups.

David Krauss, as the author of N4543 (std::unique_function<R(A...= )>), do you think it's in any way preferable to= N4159 (std::function<R= (A...)&&>), as in,
- is there a good= reason to reject N4159?
- if N4159 were adopted, woul= d there still be a good reason to adopt N4543?

Some cognitive dissonance here. How have I contr= adicted N4159?

If you want to allow non= -copyable targets, there are only two choices: 1. Let std::function accept them and define its copy construct= or to throw (or UB), or 2. Create a new, non-copyable polymorphic wrapper.<= /div>

Looking at page 8 of N4159, it suggests= the name std::movable_function fo= r what I called unique_function. I= t goes on to suggest a combined template = std::basic_function with a bool non-type parameter. I left this as an implementation detail; I don=E2= =80=99t think it=E2=80=99s a good interface. I don=E2=80=99t see it analyzi= ng alternative #1 at all.

P.S.: I just ran into this issue while attempting t= o write a Scheduler that manipulates Tasks, where a Task might be for examp= le a lambda one of whose captures is a non-copyable UniquePromise. My solut= ion was to implement Task from scratch; but in a perfect world Task would h= ave been a typedef for std= ::function<void()&&>.

That would b= e std::unique_function<void()>. Put an rvalue qualifier inside if you like. See this sum= mary from the documentation to my prototype library.

LEWG in Urbana took a number o= f straw polls to refine the direction of N4159. They=E2=80=99re in the LEWG= bugzilla but I can=E2=80=99t find the link right now.

--

---
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>.
--Apple-Mail=_AF07809F-0245-48C1-BB15-A3290151F244-- .