220 27028 article Path: news.gmane.org!not-for-mail From: Nevin Liber Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Thu, 14 Jul 2016 22:18:43 -0500 Lines: 127 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/alternative; boundary=001a113df136c70a900537a4156e X-Trace: ger.gmane.org 1468552772 6216 80.91.229.3 (15 Jul 2016 03:19:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 03:19:32 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBCE35H5S6IDBBO5MUG6AKGQEPYCGHUI@isocpp.org Fri Jul 15 05:19:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNtf0-0002Tu-HF for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 05:19:30 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id 63sf192324544pfx.3 for ; Thu, 14 Jul 2016 20:19:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=QYmkdfUSSf3zSP/XZlLatQTFnkJvycqA9zJQDjMFa4Y=; b=ZVOulxVJlBAHgZ1vwglO0t95w2JgK0fbwleKuNxaaVq/85L9DBLtoEo4wbb7coJ/XW 8HBQJOE/Qq4uJxgMf08jPGS/0JZbDHyC149h2ewQAdrDQd85NkaI1bG4pExFWcU2vBTe +/FLuU2Ebe81wJTr1385S4dsxweziVTatvMFBIvx0dK7KUXHLKtZIx5grgmAWXevf76Q lX/yZop6MuUqZ90QgIrAdAeri08nBNAdoPmXeG6Ubk1crxJv7J/X1lmVcmVx5LUY+Lb3 23dhNm7N5e7rvKY+5UTj4EBele9dARugbwG3sD6k4xAoCF/Qwb8RlQUyMjx89JWa/iRc soBQ== X-Gm-Message-State: ALyK8tIHwpqSTK3Qr8/CGRrMkP7C10imC+vK2XoFDan8fdEQTCSpdHcQaGzD9TvtQ5mXKw== X-Received: by 10.66.76.42 with SMTP id h10mr13198934paw.41.1468552764490; Thu, 14 Jul 2016 20:19:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.33.119 with SMTP id l52ls3050029otd.16.gmail; Thu, 14 Jul 2016 20:19:23 -0700 (PDT) X-Received: by 10.202.225.212 with SMTP id y203mr6411981oig.47.1468552763509; Thu, 14 Jul 2016 20:19:23 -0700 (PDT) Original-Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com. [2607:f8b0:4003:c06::22f]) by mx.google.com with ESMTPS id j63si5182902oif.161.2016.07.14.20.19.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 20:19:23 -0700 (PDT) Received-SPF: pass (google.com: domain of nliber@gmail.com designates 2607:f8b0:4003:c06::22f as permitted sender) client-ip=2607:f8b0:4003:c06::22f; Original-Received: by mail-oi0-x22f.google.com with SMTP id w18so146088219oiw.3 for ; Thu, 14 Jul 2016 20:19:23 -0700 (PDT) X-Received: by 10.202.245.20 with SMTP id t20mr7007304oih.131.1468552763081; Thu, 14 Jul 2016 20:19:23 -0700 (PDT) Original-Sender: nliber@gmail.com Original-Received: by 10.157.34.134 with HTTP; Thu, 14 Jul 2016 20:18:43 -0700 (PDT) In-Reply-To: X-Original-Sender: nevin@eviloverlord.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of nliber@gmail.com designates 2607:f8b0:4003:c06::22f as permitted sender) smtp.mailfrom=nliber@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:27028 Archived-At: --001a113df136c70a900537a4156e Content-Type: text/plain; charset=UTF-8 On 14 July 2016 at 21:57, Nicol Bolas wrote: > It's not a question of "should the standard library care about > high-performance code". It's a question of "how many high-performance > corner cases should be in the standard library?" You can keep adding stuff > to cover corner cases ad infinitum. At some point, you have to draw a line. > Why? I remember back in '12 when the big complaint was that the C++ Standard Library was too small. I must have been sleeping when that got solved. My personal criterion are: - Things that people keep inventing in multiple places - Things that are hard to write correctly Remember: we are talking about a type which, in the very next section, you > admit "will only be used in specialized cases". To me, the standard library > should be for tools that are of general use. > That's you. And no one is forcing you to use the other stuff. > That's why I like the idea of having a dedicated TS specifically for these > types of things. I'd love to see a TS full of `small_vector`, > `small_basic_string`, `inplace_function`, and so forth (but not > `flat_set/map`. Those *need to be* in the standard library). Please don't > look on TS's as some kind of ghetto for things that are not really > standard. Yes, they really are standard, they really are supplied by > compiler vendors, and they really are available. > And people who work on them expect the stuff in them to go into the IS at some point. If you wish to change the focus of TSes, you need to come to meetings and present your case. > This actually brings up a small technical deficiency with the current > proposal: no interop with `std::function`. Well, besides the obvious fact > that `inplace_function` is a callable and you could therefore shove one > into a `function` and vice-versa. > Why? What are the actual use cases for that? -- Nevin ":-)" Liber +1-847-691-1404 -- 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/CAGg_6%2BMnvpxu4mfYAHBSCh-_vNW93A8AfaLykts8%2BF_ytfSpaQ%40mail.gmail.com. --001a113df136c70a900537a4156e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 14 July 2016 at 21:57, Nicol Bolas &l= t;jmckesson@gmail.= com> wrote:
It's not a= question of "should the standard library care about high-performance = code". It's a question of "how many high-performance corner c= ases should be in the standard library?" You can keep adding stuff to = cover corner cases ad infinitum. At some point, you have to draw a line.

Why?

I remember back in '12 when the big complaint was that the C++ Standar= d Library was too small.=C2=A0 I must have been sleeping when that got solv= ed.

My personal criterion are:
  • T= hings that people keep inventing in multiple places
  • Things that are= hard to write correctly=C2=A0
Remember: we are talking about a type which, in= the very next section, you admit "will only be used in specialized ca= ses". To me, the standard library should be for tools that are of gene= ral use.

That's you.=C2= =A0 And no one is forcing you to use the other stuff.
=C2=A0
That's why I like= the idea of having a dedicated TS specifically for these types of things. = I'd love to see a TS full of `small_vector`, `small_basic_string`, `inp= lace_function`, and so forth (but not `flat_set/map`. Those need to be in the standard library). Please don't look on TS's as some kind= of ghetto for things that are not really standard. Yes, they really are st= andard, they really are supplied by compiler vendors, and they really are a= vailable.

And people who wo= rk on them expect the stuff in them to go into the IS at some point.=C2=A0 = If you wish to change the focus of TSes, you need to come to meetings and p= resent your case.
=C2=A0
This actually brings up a small technical deficiency with= the current proposal: no interop with `std::function`. Well, besides the o= bvious fact that `inplace_function` is a callable and you could therefore s= hove one into a `function` and vice-versa.

Why?=C2=A0 What are the actual use cases for that?
--
=C2=A0Nevin ":-)" Li= ber=C2=A0 <mailto:nevin@eviloverlord.com> =C2=A0+1-847-691-1404

--
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/CAGg_6%2BMnvp= xu4mfYAHBSCh-_vNW93A8AfaLykts8%2BF_ytfSpaQ%40mail.gmail.com.
--001a113df136c70a900537a4156e-- .