220 17992 <27a788e7-4912-4a58-8201-79138ddf15a3@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: First draft: Non-copyable call wrapper, std::unique_function Date: Tue, 19 May 2015 10:42:33 -0700 (PDT) Lines: 165 Approved: news@gmane.org Message-ID: <27a788e7-4912-4a58-8201-79138ddf15a3@isocpp.org> References: <59ED9069-2650-44E2-B00E-0E56ED37B83D@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_422_2104664548.1432057353927" X-Trace: ger.gmane.org 1432057361 21281 80.91.229.3 (19 May 2015 17:42:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 17:42:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBC7M5WVAKGQETFERYIQ@isocpp.org Tue May 19 19:42:41 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YulXJ-0003E9-1K for gclcip-std-proposals@m.gmane.org; Tue, 19 May 2015 19:42:37 +0200 Original-Received: by iebgx4 with SMTP id gx4sf40460795ieb.1 for ; Tue, 19 May 2015 10:42:36 -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=KL98EhbpnuSQzqtFYN2z2QoxZKBR3cSJlc13eviNRzo=; b=AZUEsXxnd6xgy+iiU5ivvM4AF1Ee/9u3IG5xbGwhGSW6Yy6lfwTkE68w+Pc/1LNGYc tCU8h1NV6NEA+Gu2M67vHdr+T76ca9W61FzKFbV2qMWN5bS1pHAIKqaZ1jFY1b3rbRzK oI7o4LoUQ77Levlb1iKUX3vJoC476CSpSOdDuqzPCMmX/m2y5SVZ9dgpQrRfyqChOwr8 b2eTxgB8ZYuNKdOMZt5wi1vID9qxHsCb5MYVzokPdoNAftk+LEinrfE/S7CwPyM8tUHO QmMqCHQrncBAti1J67P3WuC9l2HADhlaFZEpTxJAdva50329WbBcV4i0fhd4ystE9/3g q3gg== 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=KL98EhbpnuSQzqtFYN2z2QoxZKBR3cSJlc13eviNRzo=; b=GaThacQeO2JCm0JWeHKRKFoWfp8mX8F2v68hCvYr+r9hK8j0gTkSOfk+GtrlJ7lC63 weQ9XS1OQ30V3EpCvZjXRL/lR60nBl4pwb3BIk7oETJLx/OblwOvz68k9TKwW5I7EuRq 79mlcvCpmkRiU6D6m7aP+Nr3+C9ad/mN7LAXa/mSFTc5UTQ/odKOjWm15FVXCbcaLyEp 0ItshxjW26X0hdf/uGnK76hqr05OmSleT1fV/xl2QKTFZejrE6Eb/Wdp8KHjPJRwwetg FWzqBImSlLO3vJFW7CiTwD62Dzpnd2O1tg3KG67dmM7YHWguXZPxCm9Qr4B1nJdROB1j smNg== X-Gm-Message-State: ALoCoQkGkatDfg/OzB+PpggQ5Dub4xlpu5WOqypoGwjcxnRJNNLgwH5REgQVDAHvwQhhcoOWJCgG X-Received: by 10.182.219.225 with SMTP id pr1mr41414117obc.23.1432057356058; Tue, 19 May 2015 10:42:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.91.183 with SMTP id z52ls339375qgd.97.gmail; Tue, 19 May 2015 10:42:35 -0700 (PDT) X-Received: by 10.140.38.232 with SMTP id t95mr424950qgt.36.1432057354983; Tue, 19 May 2015 10:42:34 -0700 (PDT) In-Reply-To: <59ED9069-2650-44E2-B00E-0E56ED37B83D@gmail.com> 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:17992 Archived-At: ------=_Part_422_2104664548.1432057353927 Content-Type: multipart/alternative; boundary="----=_Part_423_1893908499.1432057353927" ------=_Part_423_1893908499.1432057353927 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, May 19, 2015 at 12:07:03 PM UTC-4, David Krauss wrote: > > Here=E2=80=99s a first draft of a non-copyable polymorphic call wrapper p= roposal:=20 > http://bit.ly/uniqfun > It'd probably be a good idea to let someone know if a link goes to Dropbox= =20 to download a PDF, or if it's just a HTML page on the web. You know,=20 without having to click the link. This proposal describes a variation of std::function supporting=20 > non-copyable target objects. It removes the copy constructor, and adds=20 > in-place construction of target objects. > > All comments welcome. Doesn=E2=80=99t look too scary, I just might protot= ype it. > Well, that would help. At least it would let us know the kind of work that= =20 would be involved in doing a move-transfer from `function` to=20 `unique_function`. The concern there being the changes to `function`'s=20 implementation that would need to be made. On the proposal, I think the idea of a `unique_any` could be valuable. I'm= =20 not sure if a non-moveable `unique_any` could be useful by someone, but=20 it's possible. But I don't like the idea of considering `any`s to be at all equivalent to= =20 or transformable between `function`s. While their implementations are very= =20 similar, the objects are conceptually quite distinct. Just like `vector`=20 and `string`. As such, I don't think we should explicitly support=20 transforming one into the other. I see you have `allocate_assign` and `emplace_assign`. It seems to me that= =20 you should follow the existing std::function convention. `allocate_assign`= =20 is conceptually equivalent to `function::assign`, so you should probably=20 just call it that. Also, I see no reason why it shouldn't also be able to= =20 work like `function::assign`. Similarly, `emplace_assign` should simply be= =20 called `emplace`. These sound more like the standard=20 I'm going to assume that you intended to add an `operator()` overload in=20 there somewhere. ;) However, unlike Casey Carter, I would not suggest=20 attempting to fix the thread safety problem until the committee has decided= =20 how they're going to fix it in `std::function`. We don't want two=20 completely different fixes involved. That's not to say that something shouldn't be done. It's more to say that= =20 this proposal should hold off on committing to any one solution until more= =20 is known. Lastly, bikeshedding. I'm not sure that `unique` is the right word. Oh, it= =20 conjures up thoughts of `unique_ptr`, which makes you think "move only".=20 But `unique_ptr` is about ownership of memory, while `unique_function` is= =20 just about being a move-only function wrapper. At the same time, I cannot= =20 come up with a more explicit name that doesn't sound silly (like=20 `move_only_function`). --=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/. ------=_Part_423_1893908499.1432057353927 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, May 19, 2015 at 12:07:03 PM UTC-4, David Kraus= s wrote:
Here=E2=80=99s a first draft of a non-copyable polymorphic ca= ll wrapper proposal: http://bit.ly/uniqfu= n

It'd probably be a good idea to let someon= e know if a link goes to Dropbox to download a PDF, or if it's just a HTML = page on the web. You know, without having to click the link.

<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

This p= roposal describes a variation of std::function supporting non-copyable ta= rget objects. It removes the copy constructor, and adds in-place constructi= on of target objects.

All comments welcome. Does= n=E2=80=99t look too scary, I just might prototype it.

Well, that would help. At least it would let us know the kind = of work that would be involved in doing a move-transfer from `function` to = `unique_function`. The concern there being the changes to `function`'s impl= ementation that would need to be made.

On the proposal, I think the = idea of a `unique_any` could be valuable. I'm not sure if a non-moveable `u= nique_any` could be useful by someone, but it's possible.

But I don'= t like the idea of considering `any`s to be at all equivalent to or transfo= rmable between `function`s. While their implementations are very similar, t= he objects are conceptually quite distinct. Just like `vector` and `string`= .. As such, I don't think we should explicitly support transforming one into= the other.

I see you have `allocate_assign` and `emplace_assign`. I= t seems to me that you should follow the existing std::function convention.= `allocate_assign` is conceptually equivalent to `function::assign`, so you= should probably just call it that. Also, I see no reason why it shouldn't = also be able to work like `function::assign`. Similarly, `emplace_assign` s= hould simply be called `emplace`. These sound more like the standard
I'm going to assume that you intended to add an `operator()` overload in = there somewhere. ;) However, unlike Casey Carter, I would not suggest attem= pting to fix the thread safety problem until the committee has decided how = they're going to fix it in `std::function`. We don't want two completely di= fferent fixes involved.

That's not to say that something shouldn't b= e done. It's more to say that this proposal should hold off on committing t= o any one solution until more is known.

Lastly, bikeshedding. I'm no= t sure that `unique` is the right word. Oh, it conjures up thoughts of `uni= que_ptr`, which makes you think "move only". But `unique_ptr` is about owne= rship of memory, while `unique_function` is just about being a move-only fu= nction wrapper. At the same time, I cannot come up with a more explicit nam= e that doesn't sound silly (like `move_only_function`).

--

---
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_423_1893908499.1432057353927-- ------=_Part_422_2104664548.1432057353927-- .