220 18019 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Wed, 20 May 2015 10:27:03 +0800 Lines: 134 Approved: news@gmane.org Message-ID: References: <59ED9069-2650-44E2-B00E-0E56ED37B83D@gmail.com> <27a788e7-4912-4a58-8201-79138ddf15a3@isocpp.org> <5E7FEC96-7F6B-4B2B-A165-C56F9E80C87E@gmail.com> 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=_E6E04D6E-736F-46C9-81CA-5063CE772DBA" X-Trace: ger.gmane.org 1432088861 30223 80.91.229.3 (20 May 2015 02:27:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 02:27:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBAABBD7C56VAKGQE7BXUWRA@isocpp.org Wed May 20 04:27:32 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YutjF-0007Qr-Lb for gclcip-std-proposals@m.gmane.org; Wed, 20 May 2015 04:27:29 +0200 Original-Received: by pacyx8 with SMTP id yx8sf69907521pac.0 for ; Tue, 19 May 2015 19:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=6TfB/vujV4pfMfO0KqR8mbRhf5rDhEDp0K9AFQSgum4=; b=GRQLLAS01zn34PTNTdVIkFLTvmtixz090dSh0qyI676M5rddH6WD+c6TzfKzHQuqS+ onCa55AMvwNRkAbJtr2rsP43M4w5UVUfO4c6ISyLp44FGsb9TRP/NH3av0X/lJx3KXdb U6TQGIAYw+dKhbPKk6ZoYrjgc1GZIBt9FPb6qyuxuCJ8c1YSlsjbOYcXuXohe6vCTVsn HZY5FeZhn86+PTmCgZTnkdJgDGMTXfWxIUHrigLAr9NPQBCGyEoU30NnsoLPSadecsoS qm9FnNA4A9wNXIYTUlsAc4n8lTuCg02e1WSoj9XFe+9gv1AkNue+4YoBMt5TMlcj9Qph iWWg== X-Gm-Message-State: ALoCoQkACw4PAdu2r9oNV0X3vWzRuEO2hcxslZBAOBh9RiiA7wfJIhPM+31Dfi4DqSie8ResMfSg X-Received: by 10.67.14.194 with SMTP id fi2mr42649052pad.29.1432088848369; Tue, 19 May 2015 19:27:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.4.73 with SMTP id 70ls432739ioe.0.gmail; Tue, 19 May 2015 19:27:27 -0700 (PDT) X-Received: by 10.68.213.198 with SMTP id nu6mr59299011pbc.60.1432088847515; Tue, 19 May 2015 19:27:27 -0700 (PDT) Original-Received: from nk11p04mm-asmtp002.mac.com (nk11p04mm-asmtpout002.mac.com. [17.158.236.237]) by mx.google.com with ESMTPS id px1si55398pbb.240.2015.05.19.19.27.27 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 19:27:27 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@mac.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.91]) by nk11p04mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NOM0055BMT4II30@nk11p04mm-asmtp002.mac.com> for std-proposals@isocpp.org; Wed, 20 May 2015 02:27:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-19_08:2015-05-19,2015-05-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1505200034 In-reply-to: X-Mailer: Apple Mail (2.2098) X-Original-Sender: potswa@mac.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@mac.com designates 17.158.236.237 as permitted sender) smtp.mail=potswa@mac.com; dmarc=pass (p=NONE dis=NONE) header.from=mac.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:18019 Archived-At: --Apple-Mail=_E6E04D6E-736F-46C9-81CA-5063CE772DBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9305=E2=80=9320, at 9:40 AM, Nevin Liber wrote: >=20 > The noexcept qualification of unique_function is the same as for function= .. Both allow exceptions to propagate from the move constructor when the sma= ll function optimization is applied. It=E2=80=99s a rare corner case, but t= here=E2=80=99s no static information to make any guarantee. >=20 > Fine. Should you present this in Kona, I'll bring this up in LEWG. As w= e like to say, until you present a proposal, it's your time to waste. I don=E2=80=99t understand. So far, I think noexcept-movable std::function deserves its own paper. Now = I=E2=80=99m leaning towards saying that it is feasible, but: 1. A throwing move constructor should force heap allocation (disable memory= optimization). Essentially, both std::function and std::unique_function wo= uld treat a throwing move constructor as if it didn=E2=80=99t exist, even w= hile the former may use the copy constructor. 2. std::function is inherently POCMA, and passing a non-POCMA allocator sho= uld be ill-formed. > On 2015=E2=80=9305=E2=80=9320, at 10:18 AM, Nevin Liber wrote: >=20 > std::vector and std::basic_string have noexcept(true) move constructors. = Are you saying they can't use propagate_on_container_move_assignment alloc= ators? Not quite, their noexcept specifications depend on the POCMA of the allocat= or template parameter. The idea behind POCMA (or lack thereof) is that you can keep an allocator a= ttached to a container. But it=E2=80=99s not really designed to work with p= olymorphism, which introduces the condition where the current allocator is = non-POCMA and the RHS of assignment, being POCMA, wants to replace it. If f= unction were to respect the literal meaning, any would-be attached allocato= r is at the mercy of every assignment operation. So, I conclude point #2 ab= ove. (Also, non-POCMA would be a major pain to implement.) --=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=_E6E04D6E-736F-46C9-81CA-5063CE772DBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2=80=9305= =E2=80=9320, at 9:40 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
=

The noex= cept qualification of unique_function is the same as for function. B= oth allow exceptions to propagate from the move constructor when the small = function optimization is applied. It=E2=80=99s a rare corner case, but ther= e=E2=80=99s no static information to make any guarantee.

Fine.  Shou= ld you present this in Kona, I'll bring this up in LEWG.  As we like t= o say, until you present a proposal, it's your time to waste.

I don=E2=80=99t= understand.

So far, I think noexcept-movable std::function deserves its own paper. Now I=E2=80=99m leaning= towards saying that it is feasible, but:

1. A throwing move constructor should force heap allocation (disabl= e memory optimization). Essentially, both std::function and std::unique_fun= ction would treat a throwing move constructor as if it didn=E2=80=99= t exist, even while the former may use the copy constructor.

2. std::function is inherently POCMA, and passing a non-POCM= A allocator should be ill-formed.


O= n 2015=E2=80=9305=E2=80=9320, at 10:18 AM, Nevin Liber <nevin@eviloverlord.com> wrote:<= /div>
std::vector and std::basic_string have noexcept(true) move constructors.&= nbsp; Are you saying they can't use propagate_on_container_move_assignment = allocators?

Not quite, th= eir noexcept specifications depend on the POCMA of the allocator template p= arameter.

The idea behind POCMA (o= r lack thereof) is that you can keep an allocator attached to a container. = But it=E2=80=99s not really designed to work with polymorphism, which intro= duces the condition where the current allocator is non-POCMA and the RHS of= assignment, being POCMA, wants to replace it. If function were to respect the literal meaning, any= would-be attached allocator is at the mercy of every assignment operation.= So, I conclude point #2 above.

(Also, = non-POCMA would be a major pain to implement.)

--

---
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=_E6E04D6E-736F-46C9-81CA-5063CE772DBA-- .