220 27463 <1cded9b7-eb8b-4618-8fb6-06e8e24cd87b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Mon, 1 Aug 2016 10:28:42 -0700 (PDT) Lines: 137 Approved: news@gmane.org Message-ID: <1cded9b7-eb8b-4618-8fb6-06e8e24cd87b@isocpp.org> References: <892618b7-19a9-4950-b552-ea5d5185362f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3369_1343443013.1470072523092" X-Trace: blaine.gmane.org 1470072529 16257 195.159.176.226 (1 Aug 2016 17:28:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 1 Aug 2016 17:28:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTEN726AKGQEHTVUCNQ@isocpp.org Mon Aug 01 19:28:45 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f200.google.com ([209.85.161.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bUH1B-00040g-7V for gclcip-std-proposals@m.gmane.org; Mon, 01 Aug 2016 19:28:45 +0200 Original-Received: by mail-yw0-f200.google.com with SMTP id i184sf244014090ywb.1 for ; Mon, 01 Aug 2016 10:28:45 -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=WeZ4gdAFzXzQlW9AHwEuXbgmHaz8iUSznzgp9pw1Mjs=; b=tx6nUezqj8tVi9G+NsXXGs9oHwURSRIwKX6qxmmVQPu9rXrwe6pNTFKzxyo8WHODNq SAMJ9430DYX528H31Rqjf5EJSY8mZ+ZxcTRxF7byfGzO34TUEUJi38HC/PB5yuqCThwH rUa0ALFfvdTfvOfueB/2yr1ZB+M2RB6SXVGaCBIdJbfBhFgbz4FGCbv3aw4QPiYtHZct DQxKoiRTKpW6yjStggMRdWsAW5KgvuaLNbQ1jcSiFDxsoxbdL/NKiqZc1OCFFVL3SE8u hooKkNR4HIhA0M5rLG04y39nnuq0yRNXfyPpg9+t9rKP0v3KiYYfURmjXUsiLq1m/59y CNvA== 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=WeZ4gdAFzXzQlW9AHwEuXbgmHaz8iUSznzgp9pw1Mjs=; b=rKTKdQr5JRysyp7w8Uyb5+3MSDiW7toAZLetbjb5wqtPnhxWAxqKzAH7LB/3gfsWYW ut1KTHX/ayOwjnLUsIt2SZQPZ54zPt5FdusxrZxgY7i8fQ03oZ9Q5PVSCOnU/T+GKADp IxuVsHa9ns1N7ALaiBY60M85PT0Fb1qWKl48tkWIcqirNfIClBL+2vy5kJb+Dvt7FuGb 6bqQ7HXjpTp8bd0p2TTi2qcaSPtyibOtU2m0PCI9sUKGptfTMApPkjuzx2qVOdM+wVJU 1winCvCkQ7eBwNg/szkLPYw4/ziZlYcDNYykrezWPQQkE7RcTYo/xdz/yJUgGf3s7VPm ZY8Q== 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=WeZ4gdAFzXzQlW9AHwEuXbgmHaz8iUSznzgp9pw1Mjs=; b=gQbW7icTY/6SLVum85ukAF68Yx9+j2ryuhnm+W2zmzlFobVGA5QdRNPUPMSKv69Bcn LBl5Ui2VX2xyDg9I778P8vpFhK/q213bpTjgUu0W9fRUGwxHk4eD7iyTMUajLZICHH3N B5M64Fmx9SR8OApHztIw3bWImfR/IS/YilWzCioeLoGG1XJqac7Pc8JMqNwhn+dYuxHA N2SElZFtVerraBXRN7twhmrm5uA0elnSVvq2OlePtPDTPt9P51+uq4jLJXRnrkKVk6cL RvF1ZDUEXACUvshl3+FAdYGG6WS2tH9KJlKCtNZUzmtBsN982nzGH2EFq76xcOBEYxNq dl4A== X-Gm-Message-State: AEkoout9LrZ15d350rKamJf+N8NJ6QbgSDjIS6BP4weyQ6pVAjf/VEZfEQAAt4bUe8X/Gg== X-Received: by 10.200.46.61 with SMTP id r58mr47867109qta.7.1470072524953; Mon, 01 Aug 2016 10:28:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.4.136 with SMTP id 130ls195153ioe.47.gmail; Mon, 01 Aug 2016 10:28:44 -0700 (PDT) X-Received: by 10.36.225.141 with SMTP id n135mr480837ith.2.1470072524031; Mon, 01 Aug 2016 10:28:44 -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:27463 Archived-At: ------=_Part_3369_1343443013.1470072523092 Content-Type: multipart/alternative; boundary="----=_Part_3370_602717089.1470072523092" ------=_Part_3370_602717089.1470072523092 Content-Type: text/plain; charset=UTF-8 On Monday, August 1, 2016 at 12:55:38 PM UTC-4, Tony V E wrote: > > On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas > wrote: > >> On Friday, July 15, 2016 at 3:13:58 AM UTC-4, 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). >>> >> >> That's a really good analogy. I think the principle concern for the user >> is this. `string_view` is a great interface type because you can use it to >> construct pretty much any kind of string you like. It isn't limited to just >> `std::string` construction. >> > > I don't think that's why string_view is great. Rather, string_view is > great because you probably don't need to create anything at all. You > probably just need to *use* the characters, not keep them. ie a > file_open(string_view) could (in theory at least) just use the characters > in the string_view to open the file, it doesn't need to create a string of > any kind to keep around. (unfortunately, in real life the OS probably needs > a null-terminated string). > Which is why it's a good thing that `string_view` makes it easy to construct a null-terminated string from itself, yes? It makes it easy to support those APIs that have needs that `string_view` doesn't fulfill. Admittedly, the argument isn't as compelling for `function_view`, since copying functions is very different from copying strings. So if your API needed to store the function long-term, it's more likely that you'd use either `std::function` or a specialized type of your own devising in the interface. However, that reminds me of something. I recall seeing some proposal or somesuch about an alteration of `string_view` that would know if it were null-terminated or not. -- 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/1cded9b7-eb8b-4618-8fb6-06e8e24cd87b%40isocpp.org. ------=_Part_3370_602717089.1470072523092 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, August 1, 2016 at 12:55:38 PM UTC-4, Tony V E w= rote:
On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas <jmck...@gmail.com> wrote:
On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Ne= vin ":-)" Liber wrote:
On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com> wrote:
The use case o= f "someone used `std::function` in an interface, but I use `std::inpla= ce_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 reas= on. 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::stri= ng is the wrong vocabulary type for interfaces, hence we will have std::str= ing_view.=C2=A0 Having something like llvm::function_ref that Richard Smith= described earlier might be a better fit (and LEWG might ask Carl to add su= ch a beast to his proposal).

Th= at's a really good analogy. I think the principle concern for the user = is this. `string_view` is a great interface type because you can use it to = construct pretty much any kind of string you like. It isn't limited to = just `std::string` construction.

I don't think that's why string_view is great.=C2=A0 Rather, str= ing_view is great because you probably don't need to create anything at= all.=C2=A0 You probably just need to *use* the characters, not keep them.= =C2=A0 ie a file_open(string_view) could (in theory at least) just use the = characters in the string_view to open the file, it doesn't need to crea= te a string of any kind to keep around. (unfortunately, in real life the OS= probably needs a null-terminated string).

Which is why it's a good thing that `string_view` make= s it easy to construct a null-terminated string from itself, yes? It makes = it easy to support those APIs that have needs that `string_view` doesn'= t fulfill.

Admittedly, the argument isn't as compelling for `fun= ction_view`, since copying functions is very different from copying strings= .. So if your API needed to store the function long-term, it's more like= ly that you'd use either `std::function` or a specialized type of your = own devising in the interface.

However, that reminds me of something= .. I recall seeing some proposal or somesuch about an alteration of `string_= view` that would know if it were null-terminated or not.

--
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/1cded9b7-eb8b-4618-8fb6-06e8e24cd87b= %40isocpp.org.
------=_Part_3370_602717089.1470072523092-- ------=_Part_3369_1343443013.1470072523092-- .