220 17998 article Path: news.gmane.org!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Tue, 19 May 2015 12:47:14 -0700 Lines: 78 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=089e013a1a38bc998d0516749339 X-Trace: ger.gmane.org 1432064842 1549 80.91.229.3 (19 May 2015 19:47:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 19:47:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCGNLO5F34OBBQVG52VAKGQENH2GG7I@isocpp.org Tue May 19 21:47:17 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YunTw-0003E5-2m for gclcip-std-proposals@m.gmane.org; Tue, 19 May 2015 21:47:16 +0200 Original-Received: by obblk5 with SMTP id lk5sf36643809obb.2 for ; Tue, 19 May 2015 12:47: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:mime-version:in-reply-to:references:date :message-id:subject:from: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=xjmtR7L+MigUef8pXieI2JB1R2l+RBzE3iq69aqDQeo=; b=NY0ak5zMDDqzKHxIMAd1slQ88jygqAC69HtN8T27Pc3eou+LGN7rOqb6Pw7+MUXyJz wUyjilTRr9u91CrgvrSQvdhXlPgbEQmIDqOnPnjJjMXYsvGZ/XU5hsrxw84Ad6IE+AId 8AoO5rJD8B7GvGhz2fsb4RaNDbEyVfhcZuNEkAf+93WkebdlHNbGbyYxwLG42Cd16mJJ crtxkdodBTOMmsOV9T+bOUmtJ45gMDyaDP1DmpXRVp7xjJnquCTifeowZn7jV/ixC2IZ 1GlV57WJhkH2129iPk9Lwv6bryYzMhcVQpMX5N69osWZ3j7tWNVCyXADBngYJWWA1M8I Z3JQ== X-Gm-Message-State: ALoCoQkA4EUQUCFYvP7uJanG7H4wRtGMpCeNg5sVUh5dnGSaH96ef4hTq8cBWjL5uSi6/+ncEa4L X-Received: by 10.42.203.211 with SMTP id fj19mr54099953icb.33.1432064835059; Tue, 19 May 2015 12:47:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.111.78 with SMTP id ig14ls335357igb.17.gmail; Tue, 19 May 2015 12:47:14 -0700 (PDT) X-Received: by 10.107.40.144 with SMTP id o138mr2284181ioo.66.1432064834314; Tue, 19 May 2015 12:47:14 -0700 (PDT) Original-Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com. [2607:f8b0:4001:c03::22c]) by mx.google.com with ESMTPS id o20si9015040icm.2.2015.05.19.12.47.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 12:47:14 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4001:c03::22c as permitted sender) client-ip=2607:f8b0:4001:c03::22c; Original-Received: by iepj10 with SMTP id j10so22504459iep.3 for ; Tue, 19 May 2015 12:47:14 -0700 (PDT) X-Received: by 10.50.79.167 with SMTP id k7mr23537431igx.32.1432064834173; Tue, 19 May 2015 12:47:14 -0700 (PDT) Original-Received: by 10.107.157.129 with HTTP; Tue, 19 May 2015 12:47:14 -0700 (PDT) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4001:c03::22c as permitted sender) smtp.mail=calabrese@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Matt Calabrese Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17998 Archived-At: --089e013a1a38bc998d0516749339 Content-Type: text/plain; charset=UTF-8 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. FWIW, I'm pretty sure the proposed std::any has noexcept move operations. -- --- 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/. --089e013a1a38bc998d0516749339 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 19, 2015 at 12:40 PM, Nicol 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 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 ben= efits of being able to store immobile functions outweight the benefits of h= aving noexcept move constructor/assignment.
Or just don't require invocation of the move constructor s= ince 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, ev= en 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" standpoin= t, since the language already allows things like copy/move elision for retu= rn value and argument passing. You can implement no-except move even if the= type-erased object has a move constructor that can throw.

FWIW, I'm pretty sure the proposed std::any has noexcept move = operations.

--

---
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>.
--089e013a1a38bc998d0516749339-- .