220 9161 <99dbf36e-4f1b-499b-bd17-8b7a9e056e28@isocpp.org> article Path: news.gmane.org!not-for-mail From: Scott Prager Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Any plans for enabling the use of move-only objects in std::function? Date: Thu, 6 Feb 2014 11:15:29 -0800 (PST) Lines: 165 Approved: news@gmane.org Message-ID: <99dbf36e-4f1b-499b-bd17-8b7a9e056e28@isocpp.org> References: <0532b9dd-9235-4871-b16c-656145bd0781@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_805_2644126.1391714129542" X-Trace: ger.gmane.org 1391714125 21765 80.91.229.3 (6 Feb 2014 19:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Feb 2014 19:15:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCU6PTE6UUGBBUV6Z6LQKGQEBP2CEYA@isocpp.org Thu Feb 06 20:15:34 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f72.google.com ([209.85.160.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WBUQ8-0005OR-39 for gclcip-std-proposals@m.gmane.org; Thu, 06 Feb 2014 20:15:32 +0100 Original-Received: by mail-pb0-f72.google.com with SMTP id up15sf3012221pbc.11 for ; Thu, 06 Feb 2014 11:15:31 -0800 (PST) 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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=3kM0Xhva0qAzZj6e6cUMv5e+buOx9DUs+B9IPUqQDNc=; b=E8xq6qvRKNVXtCznwkVIjh5scn9eL2+KiNW2RCIRoQ+A5dKO6DD0/Sq/0w+4eF0vNp vv1wO1EHzCa7XfV51mIXDgCUx/BTiF5ElgtUMVmm2qqjqkPxaxSPDUMPDHYiNNTuDS7E w52RCONVAHBO4DBGTtNo8hQaUprtlgoYgJZZfX5pl8im55lSQhxbgn2tzW/4xBuU3UKU MKePkYGPP/urU+bFLpuwZhLohO+Tj8hq5JO295q32yFFL15nTHbB9xRAkWRGTsoJ+HrR nun2xtdEDeZc8bKV/Q4TSe46Er6D3jUPW+lc3E4JzddJoUe5EBT+5MzaQiqjGw+sfjcs Ba8A== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=3kM0Xhva0qAzZj6e6cUMv5e+buOx9DUs+B9IPUqQDNc=; b=BuxNYytPQ3I35wJ2rVp9FRTuYVzMVZ1Jc94Avxf6jVgFh8cFR2tD4TMD/AZGoPUwAD aAULaKnadcUK5ryALBB2iIZ8V4VNAPK+ZhR93Wn3quAT2wiAktq5uWIdVbQr11UbK00c tgSpm1oJLo2UKmxdgoduEIM8qIQe+2RDy+zYlCbS3xcAHeMIwcuO/0TSUHL6IZGs7uMf kk/rLgKmeHYaCwqYUf1svS1IY87lqR+jRzauw4qHkxg3zaDZlx8kLj2C2Rx4Lrlqvbmi ZPGZImZKPASraUdndRkPK56J7VFtbA5cxMQB82RdyvMlT5joMKc5OyCtu4GeManLDiN3 AdOw== X-Gm-Message-State: ALoCoQnxr6YWCx5O5xo7jLFHyzw1jEIVWp2PZSa8NZkcVmlN1jnkoNLNzBSPfBRza3cZNFtt9IMW X-Received: by 10.66.140.8 with SMTP id rc8mr863247pab.41.1391714130982; Thu, 06 Feb 2014 11:15:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.24.49 with SMTP id 46ls723708qgq.21.gmail; Thu, 06 Feb 2014 11:15:30 -0800 (PST) X-Received: by 10.140.20.167 with SMTP id 36mr206075qgj.13.1391714130234; Thu, 06 Feb 2014 11:15:30 -0800 (PST) In-Reply-To: X-Original-Sender: splinterofchaos@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:9161 Archived-At: ------=_Part_805_2644126.1391714129542 Content-Type: text/plain; charset=UTF-8 On Thursday, February 6, 2014 1:28:16 PM UTC-5, Jeffrey Yasskin wrote: > > is it better to have std::function automatically create a > refcounted wrapper for move-only types? Or should there be a separate > move-only-function object? Or a refcounted-callable wrapper than can > then be placed into a std::function? > I had a few thoughts about this but forgot to post some of them. Given my example... > On Thu, Feb 6, 2014 at 9:45 AM, Scott Prager > > wrote: > > At > > first, I wondered why std::function couldn't point to a shared function > > object, but then I realized that the fallowing might lead to unexpected > > behavior: > > > > function f = some_stateful_functor; > > function g = f; > > assert( f() == g() ); // May fail because result may depend on > internal > > state. > Letting std::function point to a shared functor by default might lead to unexpected behavior. Also, this would further impact the efficiency of std::function, which is already much slower than passing functions without a wrapper. Making it shared when the type is move-only would be inconsistent. *(f() == g() IFF they are initialized with a copyable functor.)* This is why I asked if anyone had proposed a shared_function, specifically. f()==g() might lead to undefined behavior at that point because the state might change twice between the sequence points, but at least it wouldn't be unexpected. Also, there may be use cases for a shared_function for when one actually wants a singular state, consistent across all copies. (For example: a function that caches its results.) One thing I thought of since my initial post was that std::future has a member, share(), that produces a shared_future. To clarify, when I wrote "shared_function", I was thinking of a function that produces an std::function using a wrapper, though that would seem inconsistent in terms of API design. At the same time, I would probably be tempted to use a shared_function (type) in every single instance that I used an std::function, just in case. If I didn't do that, I'd need to overload every function I write for std::function for shared_function, but the textual implementation would be no different in each case. On Thursday, February 6, 2014 1:33:26 PM UTC-5, Nevin ":-)" Liber wrote: > > Or a throwing wrapper if an attempt is made to copy a move-only functor? > > Just adding to the design space, > -- > Nevin ":-)" Liber (847) 691-1404 > Similarly, move_only_function? Gosh, I feel like a loud-mouth right now. I don't mean to come across as an expert. I'm just opinionated. -- --- 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_805_2644126.1391714129542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, February 6, 2014 1:28:16 PM UTC-5, Jeffre= y Yasskin wrote:
is it better t= o have std::function automatically create a
refcounted wrapper for move-only types? Or should there be a separate
move-only-function object? Or a refcounted-callable wrapper than can
then be placed into a std::function?
 
I had a few thoughts about this but = forgot to post some of them. Given my example...
 
On Thu, Feb 6, 2014 at 9:45 AM, Scott Pra= ger <splinte...@gmail.com> w= rote:
> At
> first, I wondered why std::function couldn't point to a shared fun= ction
> object, but then I realized that the fallowing might lead to unexp= ected
> behavior:
>
>     function<int()> f =3D some_stateful_functor;
>     function<int()> g =3D f;
>     assert( f() =3D=3D g() ); // May fail because result= may depend on internal
> state.

Letting std::fun= ction point to a shared functor by default might lead to
unexpected beh= avior. Also, this would further impact the efficiency of
std::function,= which is already much slower than passing functions without
a wrapper.= Making it shared when the type is move-only would be
inconsistent. = (f() =3D=3D g() IFF they are initialized with a copyable functor.) This= is
why I asked if anyone had proposed a shared_function, specifically.=
f()=3D=3Dg() might lead to undefined behavior at that point because the= state might
change twice between the sequence points, but at least it = wouldn't be unexpected.

Also, there may be use cases for a shared_fu= nction for when one actually wants a
singular state, consistent across = all copies.
(For example: a function that caches its results.)

O= ne thing I thought of since my initial post was that std::future has a memb= er,
share(), that produces a shared_future. To clarify, when I wrote "sh= ared_function",
I was thinking of a function that produces an std::funct= ion using a wrapper, though
that would seem inconsistent in terms of API= design. At the same time, I would
probably be tempted to use a shared_f= unction (type) in every single instance
that I used an std::function, ju= st in case. If I didn't do that, I'd need to overload
every function I w= rite for std::function for shared_function, but the
textual implementat= ion would be no different in each case.


On Thursday, Febru= ary 6, 2014 1:33:26 PM UTC-5, Nevin ":-)" Liber wrote:
Or a throwing wrapper if an attempt is made to copy a move-only functor?=

Just adding to the design space,
--
 Nevin ":-)" Liber  <mailto:ne...@evilove= rlord.com>  (847) 691-1404

Similarly, move_only_function?

Gosh, I feel like a = loud-mouth right now. I don't mean to come across as an
expert. I'm just= opinionated.

--
 
---
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-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/<= /a>.
------=_Part_805_2644126.1391714129542-- .