220 18001 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Tue, 19 May 2015 15:06:16 -0500 Lines: 94 Approved: news@gmane.org Message-ID: References: <59ED9069-2650-44E2-B00E-0E56ED37B83D@gmail.com> <27a788e7-4912-4a58-8201-79138ddf15a3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb70e4a4e98ab051674da52 X-Trace: ger.gmane.org 1432066021 21777 80.91.229.3 (19 May 2015 20:07:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 20:07:01 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCE35H5S6IDBBYVP52VAKGQE2UV2QMI@isocpp.org Tue May 19 22:07:00 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yunn2-0001V1-A5 for gclcip-std-proposals@m.gmane.org; Tue, 19 May 2015 22:07:00 +0200 Original-Received: by lagv1 with SMTP id v1sf9747572lag.1 for ; Tue, 19 May 2015 13:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type: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=DjYjM8DW4QoD/GesPtThBLUk/Eqs9PKwyPeepnO37sA=; b=LQPyD/Ulg6Tf+HZQw3AxaefzYluwTEt/7J+sKyPJKYbEMmAZmv7N89NKXIEc0c9tL4 qv7wI19y6EK4af37BAuIg0bOav/5XVUPMm7HX7zlaShMcLsjJtmzR3VLWD3eN5KBg6Wg pSFgnlUWpQO04KVdTQHj3nUknXM+vTLtcDYfUNHJawhqoVNcHCwQq6KQ4CuVUSwRitSw he0/X7k59LvsgmFidEdwNeI+A/5DE0Ci6u9ACCuMiH+YJfFhBg7NgCEuVPIPFncpjqrQ wnycKiuYh3MEMXMbtdP2eInAmj29mNDZdRQV1Fi7DOHXwOqkfAVZMM9WFbRQrUIH9vj+ +7CA== X-Gm-Message-State: ALoCoQl1V4CBbdqsIT5i0F05qOASfEtnlJAYz/s8XT8Ja7t1cF/dSyFd3An6P6zhZMpvKVcpYNYb X-Received: by 10.180.106.10 with SMTP id gq10mr15395728wib.0.1432066019954; Tue, 19 May 2015 13:06:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.163.65 with SMTP id yg1ls100673lab.26.gmail; Tue, 19 May 2015 13:06:58 -0700 (PDT) X-Received: by 10.112.40.9 with SMTP id t9mr23623728lbk.55.1432066018264; Tue, 19 May 2015 13:06:58 -0700 (PDT) Original-Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com. [2a00:1450:4010:c03::22e]) by mx.google.com with ESMTPS id sw10si9737282lbb.158.2015.05.19.13.06.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 13:06:58 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 2a00:1450:4010:c03::22e as permitted sender) client-ip=2a00:1450:4010:c03::22e; Original-Received: by laat2 with SMTP id t2so41778638laa.1 for ; Tue, 19 May 2015 13:06:58 -0700 (PDT) X-Received: by 10.112.119.163 with SMTP id kv3mr23354943lbb.101.1432066018152; Tue, 19 May 2015 13:06:58 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.114.79.6 with HTTP; Tue, 19 May 2015 13:06:16 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of nliber@gmail.com designates 2a00:1450:4010:c03::22e as permitted sender) smtp.mail=nliber@gmail.com; dkim=pass header.i=@gmail.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:18001 Archived-At: --047d7bb70e4a4e98ab051674da52 Content-Type: text/plain; charset=UTF-8 On 19 May 2015 at 14:47, 'Matt Calabrese' via ISO C++ Standard - Future Proposals wrote: > On Tue, May 19, 2015 at 12:40 PM, Nicol Bolas wrote: >> >> Well, the reason it's not noexcept is that `unique_function` is allowed >> to store non-moveable types. And since the type is erased (unlike, say, >> non-moveable std::vector), the only way to signal an error when you attempt >> to move it is to throw an exception. >> >> That being said, I don't think the benefits of being able to store >> immobile functions outweight the benefits of having noexcept move >> constructor/assignment. >> > > Or just don't require invocation of the move constructor since you can, > instead, copy the pointer to it if it's in remote storage (and you just > force remote storage if the operation isn't noexcept, even if it fits in > the small object storage). I don't buy the "what if the move constructor > has side effects so we must call it" standpoint, since the language already > allows things like copy/move elision for return value and argument passing. > Worse, if you required it, you'd have to do a second heap allocation for moves that couldn't be embedded in the unique_function object just to call it. Ugh. -- Nevin ":-)" Liber (847) 691-1404 -- --- 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/. --047d7bb70e4a4e98ab051674da52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 9 May 2015 at 14:47, 'Matt Calabrese' via ISO C++ Standard - Future= Proposals <std-proposals@isocpp.org> wrote:
On Tue, May 19, 2015 at 12:40 PM, Ni= col Bolas <jmckesson@gmail.com> wrote:
Well, the reason it's not noexcept is = that `unique_function` is allowed to store non-moveable types. And since th= e type is erased (unlike, say, non-moveable std::vector), the only way to s= ignal an error when you attempt to move it is to throw an exception.
That being said, I don't think the benefits of being able to store imm= obile functions outweight the benefits of having noexcept move constructor/= assignment.

Or just don&= #39;t require invocation of the move constructor since you can, instead, co= py the pointer to it if it's in remote storage (and you just force remo= te storage if the operation isn't noexcept, even if it fits in the smal= l object storage). I don't buy the "what if the move constructor h= as side effects so we must call it" standpoint, since the language alr= eady allows things like copy/move elision for return value and argument pas= sing.

Worse, if you= required it, you'd have to do a second heap allocation for moves that = couldn't be embedded in the unique_function object just to call it.=C2= =A0 Ugh.
--
=C2=A0Nevin "= ;:-)" Liber=C2=A0 <mailto:nevin@eviloverlord.com>=C2=A0 (847) 691-1404

--

---
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>.
--047d7bb70e4a4e98ab051674da52-- .