220 37694 <9af6e244-f79c-db67-70a1-165a95780f4f@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: General purpose utilities for template metaprogramming and type manipulation Date: Sat, 7 Apr 2018 09:49:26 +0200 Lines: 202 Approved: news@gmane.org Message-ID: <9af6e244-f79c-db67-70a1-165a95780f4f@wanadoo.fr> References: <08cab291-d82d-4620-a825-6331deafc8fa@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5487E6407ECE25A2EDD764CE" X-Trace: blaine.gmane.org 1523087243 12122 195.159.176.226 (7 Apr 2018 07:47:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Apr 2018 07:47:23 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 To: std-proposals@isocpp.org, Nicol Bolas Original-X-From: std-proposals+bncBDH67CONY4PBBB7QUHLAKGQEY25L2EA@isocpp.org Sat Apr 07 09:47:19 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f200.google.com ([209.85.128.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4iZC-000333-Lc for gclcip-std-proposals@m.gmane.org; Sat, 07 Apr 2018 09:47:18 +0200 Original-Received: by mail-wr0-f200.google.com with SMTP id z15sf2096608wrh.10 for ; Sat, 07 Apr 2018 00:49:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1523087368; cv=pass; d=google.com; s=arc-20160816; b=m3NmGGfgdfT6ZtTG0HINIZEDJ7fqG1Hm+7FLsDZuN8er8mK189gd4xhCR6Ja0cgmaD u55UMN4L3D4Sa3QmzabvPGRiMr4LKBs8tBlib1oiwSr/zCQ7Ts91IFaiU2Xo9P1YfBYt lNptq4oM9ZDiilA7cFxKPci5+32OtRG5cUzGs9hshVj/VTamQl+zt5ZnWEgYWE5+Me8X MlEXxdfwinV2xVfGMcx+QE1Xynvm4AttpbNci/PZ351ZFMPmu3vT/rvHTsHUe2RyGxsy frhqIwU+HKIpi/qNQ9pLUMyZuBSh5/Owr/LN2k20/wdLdWf05gGy0rdce6vJGuA2HBaV 5QpQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=zOBAO5OaZ43KLLVwV4mfauhXXxgxz+ozs4hs7lug6/Q=; b=ZDqMjm7PCpsA6UC2PMfVUKy+djkIrp348EAHl5jdcLGb+ipQiv5bhFeiOfhRxB1mTf f6gA/KIzgFmXe5pRb4zFuzViFNMPyMVHoBMMcQ/z5AjbaSUdcw631wHw1KlWyKloGwvm w9F1Fb7MXs/Kn7z0W/TpkTDbcqbkqaZx/KhbIjt3GCIZJ739O5mMlheijCt6Ai5r28d3 HBikiMBt8De5H2xohCS9RzYj+sFU6AnzIkHb746t5IsJ5uGQ8epiTCgiVazajdaJPiPd kEt/Hexmgtj6YBxEO9V91N2Cn7CanC1nqMIaAupwvf7XxAlqoJmEKHtgXa17JT1FAgx/ ZWsw== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=zOBAO5OaZ43KLLVwV4mfauhXXxgxz+ozs4hs7lug6/Q=; b=mQWUSdOQP0yBEIvjobHmGyFTCpTi/ZXOxyFVikOJ61vzlJaeuK3vYg9Y2atybhhe39 ptix4yvhNy2hej7j507VH64ybN6UIdcX31GY8Xqt8Jurc4yGUfG3LmH1JWQMvXV8Hhia DrtMhacGqUNDvG5i66lecT+W1o9+7T7uwqR0iJcJcW+0+ABRZ33S2bC1R3SeBgrhVFSV qXtimBEebFjgoHaI7qOizTguFenRsQBdDU4JsPMtq/RqmRiaJhZ0Q+UbP7k17DupKY+y bLY1Gaf3E8i4hsZGMWCIAu65sbJoEtH29jhIRK44imKkQvPWlRSbtNcEgp+sVdzwlcda Zp0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :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=zOBAO5OaZ43KLLVwV4mfauhXXxgxz+ozs4hs7lug6/Q=; b=M30ASIzrRwQY4Igdg8CKL7cAHb4sy0mdDw4ych8NYb24lWd4y0Q85VctHPs2xcPher ZyS7uCgcHvjoXVtxJRN5JrN/u9ZJLWiH+9szTZgPS14lzN24ybydZ1a/6bT+reXYv7Dn zWvf8BNwdHGyiwxQ5plTTk+e+/7j+tCBeLzLzelTKX+kwLQIai4bCshc52ed4Zu4qwED OGbgfbKkWn88uMs6lF7BRcmTfS9sjY6yOHn1ZGytRHJWhFePI6oeqAA4T3vTmkwbPvU/ At6zvr97hLmOVrQctLCcU0xR3J5LhUdflGwq91N6y0AOFUVssMzC4CxvEmROibwgiY4U C X-Gm-Message-State: AElRT7HO4J1AlPiHvmMR0nF78bzKfIGa80ptDRdUtQdQ7pRVh7/iGtox +OTMXzrMQvhe9EuGcpRdZm8= X-Google-Smtp-Source: AIpwx4+V+WiZOYLgV/rDrNpOm2ntkKI4U8BsTtfC4371bc1c7iEYKafEK0+vfx8ljhKL+4EybJiuOA== X-Received: by 10.223.225.78 with SMTP id f14mr1842233wri.28.1523087368190; Sat, 07 Apr 2018 00:49:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.168.45 with SMTP id l42ls822683wrc.13.gmail; Sat, 07 Apr 2018 00:49:27 -0700 (PDT) X-Received: by 10.223.171.164 with SMTP id s33mr22598155wrc.181.1523087367290; Sat, 07 Apr 2018 00:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523087367; cv=none; d=google.com; s=arc-20160816; b=hN9RF/jB9FYUEsEU43fRBVkeK7dDPsftsuqrTMZ7xlNYsG3dyT5atEteMwlsJEQu4W dseChJiv9uOPxk1xo5ZKahFzBgwmLXfBQu0iQ3Bj69JoUrIA6OmucwTtkHZio7fIHR4L WBGT/E9oBJn7BrOAQ4Fbx8tNow3WI6adxG3rEAPMqMlBuB1P69BaI9o9hq5tvWuoprCU HRZFHA3j4leXtEXClWezl+Bsdzmy7xDmnFOFfqAuankQURiB9tnPiujnoGLzUcQ83swL /2sEGF0KZl/EQNArTZwkh+jUgAU9fmGX6bU8ox/fKKbouynagFH1gziWKCNXqGWivsap W82w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=P15dMqZBbIcjPaHA8TivWSI0AcWppkyEuSl4PbtKXow=; b=s54SeLOmCrYc69XvjAYjNskfe+Dq2SDgW49+bQqlgxZqCIDEQ3liQB35ER4mHblmLs 24sjTHMQ6j99RDjeq1xEFbiDdyGotJdrRaKqzUIJGeh5JxvIJd4seIdTh1lqm2yrWTso kWXTiYQ1wk29DXUJOE9uv8YLIjmbc+LctdLMUUeRbdVLCn0lCDyeTeqfVF1bVY32DgaR GZgb3EW8+j84uIOp1JwMdsVcscCckn7G27ZY3LyaTNeUeEefMHgc+HRQ1dvyAIYRIbOm QwUgQejfEdQtftZUQ5KvUPY7qyZO5yDz36swz5I62uDFV9WmWnOxoWGm35y5TzMA11uU KAbA== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr. [80.12.242.128]) by mx.google.com with ESMTPS id k29si6702445wre.465.2018.04.07.00.49.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 07 Apr 2018 00:49:27 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.128; Original-Received: from imac-de-vicente-botet-escriba.home ([81.53.29.90]) by mwinf5d41 with ME id XKpS1x0081wfN7D03KpSm0; Sat, 07 Apr 2018 09:49:27 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sat, 07 Apr 2018 09:49:27 +0200 X-ME-IP: 81.53.29.90 In-Reply-To: <08cab291-d82d-4620-a825-6331deafc8fa@isocpp.org> Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:37694 Archived-At: This is a multi-part message in MIME format. --------------5487E6407ECE25A2EDD764CE Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 06/04/2018 =C3=A0 18:50, Nicol Bolas a =C3=A9crit=C2=A0: > On Friday, April 6, 2018 at 5:34:08 AM UTC-4, Vincent Reverdy wrote: > > Hello all, > > Here is the current paper. Comments are welcome. > I didn't put things related to convertible/sink, because I think > it deserves its own paper. > For the typelist, I am expecting something along this line coming > from SG7. > And for the priority_tag for overloads it will probably come in a > later proposal of mine. > > > In the function traits, there seem to be some superfluous ones. Or at=20 > least, things that need to have motivation applied to them. > > `is_callable` is useful primarily as a component of other traits. > > `is_functor` is really just the intersection of `is_class||is_union`=20 > and `is_callable`. But this is really the wrong intersection. The=20 > principle motivational use for `is_functor` would be for something=20 > like `std::overload`, whose types must be classes and callable. But=20 > the thing is, `std::overload`'s callable types must be /inheritable/,=20 > since that's how `std::overload` implements stuff. So `std::overload`=20 > would really be using `is_callable` and `is_inheritable` to guard the=20 > types it is provided. Right. My implementation checks only for the is_inheritable part. The=20 callable part is checked when calling it :( Having a is_callable could help, to diagnose as soon as possible when=20 when overload takes something that is not callable, but this doesn't=20 mean that it is callblae with the arguments it will be called. Is when we call it that we really check for the Callable. To be pedantic, we need is_callable, but from the pragmatical point of=20 view, it is is_invocable that is useful. BTW, We need that std::invoke is contexpr. Was this fixed already? > > So, can you provide a use case for `is_functor`, where code can accept=20 > *any* class with an overloaded `operator()`, even if it cannot inherit=20 > from it? If not, then this is not needed. > > `is_function_object` seems dubious. See, the most useful place one=20 > might see it is in algorithms. But quite frankly, algorithms ought to=20 > be adjusted to use `std::invoke`, so that they can take member=20 > pointers too. > > So, can you provide a use case for an interface that /should/=20 > explicitly exclude member pointers? > > `is_closure` seems not just useless but anti-useful. Closures and=20 > lambdas are nothing more than syntactic sugar. Any interface that=20 > accepts a lambda ought to also be able to accept a user-defined class=20 > type. To do otherwise creates a user-hostile interface; we /don't=20 > want/ users to be able to restrict interfaces in this way. > > Can you provide a use case for this trait that doesn't make the=20 > interface actively worse than using `is_functor`? Agreed for all the comments. We need use cases. However I will not be against (your approach Vincent) to request traits=20 for everything defined in the standard. But if we don't have use cases=20 for those traits, we don't need to spend time on them. Vicente --=20 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 e= mail 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/9af6e244-f79c-db67-70a1-165a95780f4f%40wanadoo.f= r. --------------5487E6407ECE25A2EDD764CE Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 06/04/2018 =C3=A0 18:50, Nicol Bolas = a =C3=A9crit=C2=A0:
On Friday, April 6, 2018 at 5:34:08 AM UTC-4, Vincent Reverdy wrote:
Hello all,

Here is the current paper. Comments are welcome.
I didn't put things related to convertible/sink, because I think it deserves its own paper.
For the typelist, I am expecting something along this line coming from SG7.
And for the priority_tag for overloads it will probably come in a later proposal of mine.

In the function traits, there seem to be some superfluous ones. Or at least, things that need to have motivation applied to them.

`is_callable` is useful primarily as a component of other traits.

`is_functor` is really just the intersection of `is_class||is_union` and `is_callable`. But this is really the wrong intersection. The principle motivational use for `is_functor` would be for something like `std::overload`, whose types must be classes and callable. But the thing is, `std::overload`'s callable types must be inheritable, since that's how `std::overload` implements stuff. So `std::overload` would really be using `is_callable` and `is_inheritable` to guard the types it is provided.
Right. My implementation checks only for the is_inheritable part. The callable part is checked when calling it :(
Having a is_callable could help, to diagnose as soon as possible when when overload takes something that is not callable, but this doesn't mean that it is callblae with the arguments it will be called.
Is when we call it that we really check for the Callable.
To be pedantic, we need is_callable, but from the pragmatical point of view, it is is_invocable that is useful.
BTW, We need that std::invoke is contexpr. Was this fixed already?

So, can you provide a use case for `is_functor`, where code can accept *any* class with an overloaded `operator()`, even if it cannot inherit from it? If not, then this is not needed.
`is_function_object` seems dubious. See, the most useful place one might see it is in algorithms. But quite frankly, algorithms ought to be adjusted to use `std::invoke`, so that they can take member pointers too.

So, can you provide a use case for an interface that should explicitly exclude member pointers?

`is_closure` seems not just useless but anti-useful. Closures and lambdas are nothing more than syntactic sugar. Any interface that accepts a lambda ought to also be able to accept a user-defined class type. To do otherwise creates a user-hostile interface; we don't want users to be able to restrict interfaces in this way.

Can you provide a use case for this trait that doesn't make the interface actively worse than using `is_functor`?
Agreed for all the comments. We need use cases.

However I will not be against (your approach Vincent) to request traits for everything defined in the standard. But if we don't have use cases for those traits, we don't need to spend time on them.

Vicente

--
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/9af6e244-f79c-db67-70a1-165a95780f4f= %40wanadoo.fr.
--------------5487E6407ECE25A2EDD764CE-- .