220 18002 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Tue, 19 May 2015 13:16:47 -0700 (PDT) Lines: 95 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/mixed; boundary="----=_Part_539_814529928.1432066607590" X-Trace: ger.gmane.org 1432066612 31934 80.91.229.3 (19 May 2015 20:16:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 20:16:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMFU52VAKGQEEK7SPDI@isocpp.org Tue May 19 22:16:51 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YunwX-0004n6-HX for gclcip-std-proposals@m.gmane.org; Tue, 19 May 2015 22:16:49 +0200 Original-Received: by qkzz198 with SMTP id z198sf25137836qkz.1 for ; Tue, 19 May 2015 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=1CSevgexgItJ3Dkf6LtEWRmUxnWKeI7m6S36OIxb9iw=; b=FTkgCubvfmRSbYdKIHTDaYAR9tjhgX/y8ethvOtHALEF3nyU7TupNAwub9qShu8Kcj 4Q3T+5hz5KtMlQ2bvP0IsE9Z6MgsAu51b7+nLHt+i8Ar3P78tDc/hmnqF5w2vrUXKjk9 hfWtpXnHoLba+HABk4H8zSXQ7QyMTXQ1tYx5xu3wKTbuCbKiOnY1zs7d+WKK4ePS/PZQ wyOU0h8iD1EPKrdL8u1j2nSJGmM4MCZHvnNlnUbmFzshPFV+IOCNXnO3mxzp3bvwFC6E FjMJF0HAIs+s4m+ir3UPGl8z3J4aLUKGS26E8zoSLzNiH/BIP/f8/akeaTJzDIz1Hlc2 gbhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=1CSevgexgItJ3Dkf6LtEWRmUxnWKeI7m6S36OIxb9iw=; b=hB0g8/H/RLy7xSX/ghgw1WJMndDMVn22gawTmknAI56zrsDEBaQKfQYchaPbK9bnaD tBISS0loVv9yE4sR0QXUDkLntd6N8d+ZMgadRiQBmsG2m1Gp6294AQq+BN0mgOSST0jV 2tTOUpEkUJmjPIvvDDoSmIA2KGeJBn+G2NrAQKfSBq1LIxskTBHKJEurf/cv0ScHxyo6 RRNNJH9GFmnicQZsrUXGzBBgRmqU0aaOyx16G4+fNa3qfy4qCEbyKN5reuhWGqJ1jA1+ vy29wyQtGoPj2khLMGOVaPQx9eXFoS+c6sb2ZjuAREBnspoOVhmFDwdx9+Crq34wQk3b Ad4Q== X-Gm-Message-State: ALoCoQkvT/ubAVd9XLn3OL/VNM8jGSjJ4v31zV159qI+tbYX8/zDUNXvYuQWF6aHHOQjDnOFA1E3 X-Received: by 10.236.228.167 with SMTP id f37mr42507834yhq.21.1432066608578; Tue, 19 May 2015 13:16:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.98.8 with SMTP id n8ls398194qge.31.gmail; Tue, 19 May 2015 13:16:48 -0700 (PDT) X-Received: by 10.140.37.129 with SMTP id r1mr140029qgr.18.1432066608004; Tue, 19 May 2015 13:16:48 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:18002 Archived-At: ------=_Part_539_814529928.1432066607590 Content-Type: multipart/alternative; boundary="----=_Part_540_1743733918.1432066607590" ------=_Part_540_1743733918.1432066607590 Content-Type: text/plain; charset=UTF-8 On Tuesday, May 19, 2015 at 3:47:15 PM UTC-4, Matt Calabrese 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. > You can implement no-except move even if the type-erased object has a move > constructor that can throw. > Right. Obviously. Sorry, wasn't paying attention. So yes, make it noexcept. -- --- 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/. ------=_Part_540_1743733918.1432066607590 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tuesday, May 19, 2015 at 3:47:15 PM UTC-4, Matt= Calabrese wrote:
On Tue, May 19, 2015 at 12:40 PM, Nicol= Bolas <jmck...@gmail.com> wrote:
Well, the reason it's not noexcept is that `unique= _function` is allowed to store non-moveable types. And since the type is er= ased (unlike, say, non-moveable std::vector), the only way to signal an err= or 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" standpoi= nt, since the language already allows things like copy/move elision for ret= urn value and argument passing. You can implement no-except move even if th= e type-erased object has a move constructor that can throw.

Right. Obviously. Sorry, wasn't paying attent= ion.

So yes, make it noexcept.

--

---
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>.
------=_Part_540_1743733918.1432066607590-- ------=_Part_539_814529928.1432066607590-- .