220 27403 <892618b7-19a9-4950-b552-ea5d5185362f@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: Sun, 31 Jul 2016 06:53:22 -0700 (PDT) Lines: 100 Approved: news@gmane.org Message-ID: <892618b7-19a9-4950-b552-ea5d5185362f@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_723_230869431.1469973202280" X-Trace: blaine.gmane.org 1469973223 1989 80.91.229.8 (31 Jul 2016 13:53:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2016 13:53:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBU4F7C6AKGQEMWEFR4Y@isocpp.org Sun Jul 31 15:53:29 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTrBF-0000Ri-Vy for gclcip-std-proposals@m.gmane.org; Sun, 31 Jul 2016 15:53:26 +0200 Original-Received: by mail-it0-f72.google.com with SMTP id c126sf104177559ith.3 for ; Sun, 31 Jul 2016 06:53:25 -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=7dO+aYG7pAhxZC4ZdYDe1bQH/cw1HQUkXOsPEUgc6eM=; b=HYMDo7RYB1QhJYUZT+b3AvHWHQe4O9mfDWwYzqz6+12H2C0zfbZp6+4pT+AG9G9dK8 v+MyonF5AgChGKsr16t65KktdPN0drJqhZ6A1/xQ0PbFGxp8WEvF+gSYx239DMlDu7kT LgqxeBNMKqYUNaYbzudEsSzAG6i9/khoJzL3zZfhfsO1Jh+bIcv4OTUsdeP6QNUliXtA P+Pz6l+eU2ULU6kAl2ue85jJELGShOCS7uU4g0qndYce/FaZPMQ1uEx4rJUm8C7OaI5K +Fl8bS4sKVvZEcxGVelf3Zpv8Mdx/p+hP1K1hkRZVJsU5awvwpSHwhTL4jLjrSlnCwgD JiCA== 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=7dO+aYG7pAhxZC4ZdYDe1bQH/cw1HQUkXOsPEUgc6eM=; b=pwjeRQ8pglh/4v9ADWt/0hqzSWXLme+IqUzLv/c6d9LUxE+0FzdVgjwfeY3LybEb0O E+x+gkIfRttgEd99n0SISybj8QusdhSsW5IO9D9rpgJIDhvbZpI+jmSOso6dqDRs3pY3 gWqV7hs7ztu6ipnn5mx7d1j6JZ8iVfzPrmilin/5/5l/lsVyzQPyb3scBMJ97Xy3WfIE wktQsj1xQNJdqEa35EG/Y2ZtBqM+IDlABF/7n/vFO7Z9XHtMTX2DU7XOmeDWM6BdUgMi Ofs3XUYaKg8L75wn5HfEDzn4PHeCWXGLGbfppdiUlPpaEnEneYX2q6pZLsX5tltZWbnZ 1URw== 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=7dO+aYG7pAhxZC4ZdYDe1bQH/cw1HQUkXOsPEUgc6eM=; b=jOA3Fe+sGJzyTcH19yj3FUlLMNvvBJT9SRlfmKsSrLY6NvRDUoA+a+xrZCS3jlUaj/ b3l9G5kaGYkZ8ht8OMUUWbAe9iu/cjQW6rRjYdebuBGzTBgpcQm8BbL7H0neeKnhYDPM iXkrr70mTlxsCJimdKDPXgHHevQpqcql84Q2cbAoR2PqTJBOw2xHXzN+tbOXxwhdgGhx 5XdsAVaObjctfMvyJeA81Jf59tXFQvd8YUumqOnAJQM8BiaMO4y1tDOjJd7jcDE9JLzr MMbMGJW9OVNiA8zVKqhRbbo2KNnc7sds5apPnp3UxapP/7v656EyQjKbyMkaBmaInoWE PIPQ== X-Gm-Message-State: AEkooutZ7uMjM095VdK5J80P3DWrOjBlX2YdfcXQZ4mvW8iaA95tfq1c8zW/nMEdxfEIqQ== X-Received: by 10.107.201.70 with SMTP id z67mr44482892iof.22.1469973205013; Sun, 31 Jul 2016 06:53:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.189.196 with SMTP id x187ls1327190ite.14.gmail; Sun, 31 Jul 2016 06:53:23 -0700 (PDT) X-Received: by 10.36.50.75 with SMTP id j72mr370223ita.5.1469973203557; Sun, 31 Jul 2016 06:53:23 -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:27403 Archived-At: ------=_Part_723_230869431.1469973202280 Content-Type: multipart/alternative; boundary="----=_Part_724_239184812.1469973202280" ------=_Part_724_239184812.1469973202280 Content-Type: text/plain; charset=UTF-8 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. Would a hypothetical `function_view` have an interface that could be used to construct any kind of function wrapper? That is, how could it expose the actual type of the callable in such a way that someone could copy it out? Though we could probably get away with just allowing it to be converted to a `function`. Or rather more specifically, allowing `function` to be constructed from a `function_view`. -- 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/892618b7-19a9-4950-b552-ea5d5185362f%40isocpp.org. ------=_Part_724_239184812.1469973202280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe std::function is the wrong voca= bulary type for interfaces, just like std::string is the wrong vocabulary t= ype for interfaces, hence we will have std::string_view.=C2=A0 Having somet= hing 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 t= hink the principle concern for the user is this. `string_view` is a great i= nterface type because you can use it to construct pretty much any kind of s= tring you like. It isn't limited to just `std::string` construction. Wo= uld a hypothetical `function_view` have an interface that could be used to = construct any kind of function wrapper? That is, how could it expose the ac= tual type of the callable in such a way that someone could copy it out?
=
Though we could probably get away with just allowing it to be converted= to a `function`. Or rather more specifically, allowing `function` to be co= nstructed from a `function_view`.

--
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/892618b7-19a9-4950-b552-ea5d5185362f= %40isocpp.org.
------=_Part_724_239184812.1469973202280-- ------=_Part_723_230869431.1469973202280-- .