220 17852 <7e9a7010-cc2c-432f-980d-dc17e7d478fa@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: smart function pointer proposal Date: Thu, 14 May 2015 14:05:46 -0700 (PDT) Lines: 95 Approved: news@gmane.org Message-ID: <7e9a7010-cc2c-432f-980d-dc17e7d478fa@isocpp.org> References: <736df6af-cd5e-4625-a4bb-be3cfd49a67e@isocpp.org> <2A6D8713-02D7-420A-A3D9-17F7C1D2C7F6@mac.com> <662b2b76-f8b2-4189-8eac-4b1d3a64e319@isocpp.org> <04e8b03f-5f43-41b2-8039-19ca11d31dfc@isocpp.org> <8a1bb50e-aa86-4f29-9906-c279b2413914@isocpp.org> <2789e87a-9b41-4f95-ab17-9fe15d015a0f@isocpp.org> <502f2509-6aef-4776-8b40-ce6c8cb72c24@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_43_842675825.1431637546656" X-Trace: ger.gmane.org 1431637552 11284 80.91.229.3 (14 May 2015 21:05:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 May 2015 21:05:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBK442SVAKGQEI3UUQWY@isocpp.org Thu May 14 23:05:50 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yt0KC-0003Rp-S9 for gclcip-std-proposals@m.gmane.org; Thu, 14 May 2015 23:05:49 +0200 Original-Received: by yhb65 with SMTP id 65sf72463153yhb.3 for ; Thu, 14 May 2015 14:05:48 -0700 (PDT) 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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=LWeybpqihF1RxQsznbomrbP+mEUbb/Rk7h2Ljlu1J/0=; b=tyo2hSU3jHjnYPya/SKofxqh4vlx7StjqdfrDOkIx6/RZ2+hxwYDcSbwKcCN+Dmap1 hoWifmcB+KL58k1B7cX0w3zZgqJq6M+VXRl/rnzYmb3IL8vnhOXbdueeZhTatItFOvRX UWfkezBgL591KCY/ANq1X0Qe5HxMHU4xGlU9YgRJN4UpCyAgWjpmhyOYJNy2edFmRBNX pz4q+dfJoeMlNnye9yXzAiC3F+aSMuWmIQJ0m7Op3nvUCRG92BvmlV5NR/kFQAvO39Vy QcnXpplvfB1AJwWUj48flnI2u1IsvycfqC3kRudlytg72DfoJi6E30W4gSNQlLfMCEfo eZqw== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=LWeybpqihF1RxQsznbomrbP+mEUbb/Rk7h2Ljlu1J/0=; b=SSmIArxh8IFy9m63hnbkdJUbN0gzbabZUbi2y0WS1G3Yj0jhMVjFZJBQarqXfNi6iW SAd1SsmLnrGDroSRUi9ogLuxEhxlBA8i0mLkP31rE41XlBzBwSmVAlKO44pOo+ZYaVoi tsK596ZUqJLN8GI/cRNxGeUmMv1Rw/XSO6b5Z3EUApZKFSlZkAl+NGCjND6XbrFGtxM0 1QftF/YnGCob4PTKsJeTPvn22U1f+71XOy+kPc6mHdu/479cOdWItpXti1eS025yC/Xm ylml+gIPRnUYz8D1moPJSMybH1p5FCd1GiTj0832ASsXL6dl5mA4sKkSv9ygjvchrbtA 3NOQ== X-Gm-Message-State: ALoCoQkWfrxCDdQ4YJoASCj0lB0RStdooGo/Nvt2AGMKZiGNshAlgdCATyPRoRArwqzU5azfcudg X-Received: by 10.140.151.85 with SMTP id 82mr8594023qhx.1.1431637548039; Thu, 14 May 2015 14:05:48 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.48.9 with SMTP id n9ls1413513qga.58.gmail; Thu, 14 May 2015 14:05:47 -0700 (PDT) X-Received: by 10.140.31.196 with SMTP id f62mr124112qgf.30.1431637547425; Thu, 14 May 2015 14:05:47 -0700 (PDT) In-Reply-To: <502f2509-6aef-4776-8b40-ce6c8cb72c24@isocpp.org> 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:17852 Archived-At: ------=_Part_43_842675825.1431637546656 Content-Type: multipart/alternative; boundary="----=_Part_44_197938810.1431637546656" ------=_Part_44_197938810.1431637546656 Content-Type: text/plain; charset=UTF-8 I guess the fundamental issue I have with comparing arbitrary function objects of this type is the answer to this question: What exactly are the use cases where you're asking two function objects if they're the same? We're talking about opaque callables here. You have two functions, who's implementations could come from anything. So what is the point of testing if one is equal to another? What are you trying to achieve by doing so. I have never been in a situation where I had some need to know if one std::function I had received was equivalent by some measure to another. Your proposal also doesn't seem to explain the need for such a feature. It simply declares, "Equality comparison is a fundamental operation a smart function pointer needs to support," as though it were an undeniable fact that people obviously have need to compare two arbitrary callables. When you said "Equality comparison is the key feature...", you go on to show an example of its use. But this doesn't explain the *need* for it. The closest your proposal gets is an example of an event handling interface. The function you pass in to attach it to the container is also used as the handle to unregistering the function. But personally, I prefer to use a handle returned from the registration function. That way, I can keep around a small handle object rather than this big, bulky std::function. It also makes the interface more clear, if you're allowed to do things like swap which function is registered, or add other attributes to a specific registration (like a priority or whatever). So why do you need to compare two arbitrary callables that have been given to your piece of code? -- --- 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_44_197938810.1431637546656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess the fundamental issue I have with comparing arbitr= ary function objects of this type is the answer to this question:

Wh= at exactly are the use cases where you're asking two function objects if th= ey're the same?

We're talking about opaque callables here. You have = two functions, who's implementations could come from anything. So what is t= he point of testing if one is equal to another? What are you trying to achi= eve by doing so.

I have never been in a situation where I had some n= eed to know if one std::function I had received was equivalent by some meas= ure to another. Your proposal also doesn't seem to explain the need for suc= h a feature. It simply declares, "Equality comparison is a fundamental oper= ation a smart function pointer needs to support," as though it were an unde= niable fact that people obviously have need to compare two arbitrary callab= les.

When you said "Equality comparison is the key feature...", you = go on to show an example of its use. But this doesn't explain the need for it.

The closest your proposal gets is an example of an event = handling interface. The function you pass in to attach it to the container = is also used as the handle to unregistering the function. But personally, I= prefer to use a handle returned from the registration function. That way, = I can keep around a small handle object rather than this big, bulky std::fu= nction. It also makes the interface more clear, if you're allowed to do thi= ngs like swap which function is registered, or add other attributes to a sp= ecific registration (like a priority or whatever).

So why do you nee= d to compare two arbitrary callables that have been given to your piece of = code?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_44_197938810.1431637546656-- ------=_Part_43_842675825.1431637546656-- .