220 27043 article Path: news.gmane.org!not-for-mail From: Giovanni Piero Deretta Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Fri, 15 Jul 2016 03:00:27 -0700 (PDT) Lines: 85 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_94_2116630029.1468576827766" X-Trace: ger.gmane.org 1468576848 26036 80.91.229.3 (15 Jul 2016 10:00:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 10:00:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDEP3I7TGEIL32FCXQCRUBD4E4NWE@isocpp.org Fri Jul 15 12:00:41 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNzvA-0000fj-Fs for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 12:00:36 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id ez1sf82185450pab.0 for ; Fri, 15 Jul 2016 03:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=M1ab5T/7XZ4tOi5qrEG+KmeZvCNKFjpPGKmPjeYp4/o=; b=vWZNxeD5xZe31IacghVy6eDeDlA7xT1Goo+194Gd/AjDkcEbPfZgEHCPaIobYXOyWa 76IEMwFvhrMlomzHGB4Ik9n30ZxMUJNzo22S1nX644P/v8FHqrK3lITF++PY10LON495 wBQ1qEFeiEwjzqQC2rCHs/pDB+YJI1HQxjOfeHBO/Wm+tZ2RfY+RaM+0qYML7NFtxu5T 7DzKbV5MP+waduOmHeKYnchqy3aDc59LOKF5aMfq+xXtU05Bcxz+k7XW+FtM515LI4PZ cbBt1DjhDMTr0NmXTa0BNukhe+ZYQnkK3pGop5PJGpeRdriaad0ljxfovDwlyx19zcKJ 6VSA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=M1ab5T/7XZ4tOi5qrEG+KmeZvCNKFjpPGKmPjeYp4/o=; b=QY0k4XjzZADqcSfNRDXYs1iDG9NHR5YXeIHv+mAheC6mtK4P2w2XrcBJJbQwEWMaqm CRxsX3NoYAmCiqHDauwMJ0pCwdkLIn8RGmIQsTarXb5SUcXVIW0BcnVGLZ1xLSWeHdI+ 1x3ALScdjv1Y3gTu+Azky0tfQsbGxiV0xgv4+IJQEUYTOI8+yGJMhle6MRPCbAfBKfQd 6hoD8RBZZuEvtEPueWEesJmZiUgGS51yiG0IfV6FXEjlUOz5TumWWBpqhrSf2/Gd/Acn kju9g6bUYubnf89RKjNdedXbCZfamVv/XrrACIKCBfo8Y7AH46Z6ZyT64aXPIwmdSBns kn9A== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=M1ab5T/7XZ4tOi5qrEG+KmeZvCNKFjpPGKmPjeYp4/o=; b=WY1lIqiMQEEpi1coPcgsWhmVE1vT86oM1I3isXjjBPcwqGxivDJnTmDEMu6au0glPJ FnFKO8qi/nsbZOkE+xIfdyN+n0yf6GoOoDzj0cxcsFlFdwDcMbpfd9RNyab1nbdZjXkc oXK/y4DKcIYzIhXLHJZ57nKfCfi9snYrlzYPsgh0XlVuva5w9X93kX1yt84kNHRcb6a2 ERr6YK4fnAXgdJz654ME8TltBLPTR4567yIO4sNJ6evOG3JSdT1P1BNqGGOVwr+M1+uR W5X3Y5mMhMFtRmtO26Z//ATVmGTq5fhIrTlYCP0hVwYAMN5UU5pN1MDAsro2o1hxIaS7 vskw== X-Gm-Message-State: ALyK8tLJ8vdb8V2qvsa+Om7WhAsyk4oCZ8q6b2UHbxV8hjHYYKvJaVFfKloPmlddDdLSDg== X-Received: by 10.67.24.33 with SMTP id if1mr8065298pad.29.1468576830405; Fri, 15 Jul 2016 03:00:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.167.3 with SMTP id q3ls1404793ioe.49.gmail; Fri, 15 Jul 2016 03:00:29 -0700 (PDT) X-Received: by 10.36.20.201 with SMTP id 192mr1209611itg.8.1468576829003; Fri, 15 Jul 2016 03:00:29 -0700 (PDT) In-Reply-To: X-Original-Sender: gpderetta@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:27043 Archived-At: ------=_Part_94_2116630029.1468576827766 Content-Type: multipart/alternative; boundary="----=_Part_95_318663664.1468576827766" ------=_Part_95_318663664.1468576827766 Content-Type: text/plain; charset=UTF-8 On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin ":-)" Liber wrote: > > On 14 July 2016 at 23:30, Nicol Bolas > > wrote: > >> The use case of "someone used `std::function` in an interface, but I use >> `std::inplace_function` internally, and I need to talk to their code." >> Right now, `std::function` is how lots of C++ code takes callbacks, and for >> good reason. But if I've wrapped some function in an `inplace_function`, I >> still need to be able to talk to them. >> > > Maybe std::function is the wrong vocabulary type for interfaces, just like > std::string is the wrong vocabulary type for interfaces, hence we will have > std::string_view. Having something like llvm::function_ref that Richard > Smith described earlier might be a better fit (and LEWG might ask Carl to > add such a beast to his proposal). > -- > Isn't an std::function containing an std::reference_wrapper guaranteed not to allocate? Is that different from llvm::function_ref? -- gpd -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e94d4f6d-e2c8-4b7d-a13a-0c10754212fd%40isocpp.org. ------=_Part_95_318663664.1468576827766 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin "= :-)" Liber wrote:
On 14 July 2016 at 23:30, Nicol Bolas <<= a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"DQgNm7F_C= wAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retu= rn true;" onclick=3D"this.href=3D'javascript:';return true;">jmck..= ..@gmail.com> wrote:
The use case of "someone used `std::function`= in an interface, but I use `std::inplace_function` internally, and I need = to talk to their code." Right now, `std::function` is how lots of C++ = code takes callbacks, and for good reason. But if I've wrapped some fun= ction in an `inplace_function`, I still need to be able to talk to them.

Maybe std::function is the wrong vocabulary t= ype for interfaces, just like std::string is the wrong vocabulary type for = interfaces, hence we will have std::string_view.=C2=A0 Having something lik= e llvm::function_ref that Richard Smith described earlier might be a better= fit (and LEWG might ask Carl to add such a beast to his proposal).
-- <= br>

Isn't an std::function containing = an std::reference_wrapper guaranteed not to allocate? Is that different fro= m llvm::function_ref?

-- gpd

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/e94d4f6d-e2c8-4b7d-a13a-0c10754212fd= %40isocpp.org.
------=_Part_95_318663664.1468576827766-- ------=_Part_94_2116630029.1468576827766-- .