220 8024 article Path: news.gmane.org!not-for-mail From: "R. Martinho Fernandes" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A proposal to add call traits to the Standard Library Date: Wed, 4 Dec 2013 02:23:15 -0800 (PST) Lines: 186 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="----=_Part_4544_16006054.1386152595860" X-Trace: ger.gmane.org 1386152593 27932 80.91.229.3 (4 Dec 2013 10:23:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Dec 2013 10:23:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDXL3FEUYQARBFEF7SKAKGQE2CS2XVA@isocpp.org Wed Dec 04 11:23:18 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f72.google.com ([209.85.128.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vo9by-0006LA-8L for gclcip-std-proposals@m.gmane.org; Wed, 04 Dec 2013 11:23:18 +0100 Original-Received: by mail-qe0-f72.google.com with SMTP id 5sf35730376qeb.3 for ; Wed, 04 Dec 2013 02:23:17 -0800 (PST) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=WpkM4hkfhEn94pOF95TSK12Yu+XQb2HjPwUzXR3Q3pU=; b=ZKHjvSYfVjZ4DdCnSxDKA+XYVkGEvyHNeE9hmoN7GW32yax3duUDewget7rv/kdbF2 rGMqcn4T5BSKJxPShO5orhoen2DjVm6HIsF9qYf+lwv4nWu04JM+KUwlrbUKE+FDIWBO Ck72u0822ppJ2g+dSU4I7vNGzKfqn3QoG3SR6qLhrqm1q9aCBx7zwBiqTYiEoX7hC2yL Nxk4gSRNtX6S4KY/9hAIFtIPidsP5d+H1qBgnaTqU+OMi5VM5XaC5Z1ho9eY9QuIvQ+1 kU8pRSJwBRvNpd3p+bXAzc87sjr9P+8doAQQIMJ70EMRPS427ehCG/OtXNpYZay5ZSQY SxOw== 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=WpkM4hkfhEn94pOF95TSK12Yu+XQb2HjPwUzXR3Q3pU=; b=PlEPGN73oB+Qy94D9oSlIqUZ/7Cu0FTj9+rkdGB+PaZFAxa2ctSTTog2PpAvmE/ZT0 WJe1HuvdueF1PqaZr9l7Mptr36pQKuwYXCp2CEe6sarxOPr5iuiEb8mIv+6QbuRlkjZa 8K2Pgm7kxKP+rLJV9sgO1Q/zB4ogYka3dCXmkTwjEoIkGHf+cfK4sWcJ880VDZrA9T9z qpCuleisWuuEmFOHXLFR2YwWilDGThccHi8/3HtonHL92zUqOe2TV4Bfj8yChMWqU/7d 66w+7r0aGmURTP2G5qUfSM2qrnr3unF3Ip28oKtUVJExM4JiWO6zgdRC81esIaemlrVL DkOw== X-Gm-Message-State: ALoCoQmiyF+fTUmURXHDhhdaMEFqTefqbDmkfs4+ZnK/XcQmix64owL3KieUsXrRS0dgg0ojXfFp X-Received: by 10.58.249.208 with SMTP id yw16mr17007782vec.10.1386152597390; Wed, 04 Dec 2013 02:23:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.27.33 with SMTP id q1ls233410qeg.80.gmail; Wed, 04 Dec 2013 02:23:16 -0800 (PST) X-Received: by 10.49.88.5 with SMTP id bc5mr1406681qeb.4.1386152596608; Wed, 04 Dec 2013 02:23:16 -0800 (PST) In-Reply-To: X-Original-Sender: martinho.fernandes@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:8024 Archived-At: ------=_Part_4544_16006054.1386152595860 Content-Type: text/plain; charset=ISO-8859-1 There are several things that irk me here, so I'll just list them in order. For qualification I am on the camp that things this kind of thing is nigh-useless and mostly abuseful. There are very few cases where one really needs to obtain such information, and in those cases this proposal is very limited because we haven't been in a world of monomorphic callables in a long time and with C++14 the relevance of that world is about to decrease drastically. We need different tools (I'd like: a Callable concept thingy, and for the niche scenarios some overload introspection thingy). That said, let's go through it. The document claims that "the interface design is chosen to match the type_traits library", but the `type_traits` library doesn't use template variables. However, there are times, in which we cannot provide a truly generic > solution, and > where we are forced to take type information into account, and hence we > need a generic > way to query information about the instantiated type(s). > I have written a lot of generic code that uses callable objects and I never needed this, so I got curious about the use cases (i.e. that "I must be missing something" feeling). However the proposal document does not provide an example. It provides an artificial example of usage, but that isn't convincing because "You can use it to demonstrate the feature featured in this proposal" is not an interesting example. (The example irks me particularly because `make_stdfunction` seems quite silly to me; to me it feels a bit like a `make_vector(T x) { return vector{x}; }`, with the difference that the vector will have a richer interface than T, but std::function does not have a richer interface than the source. One can just pass the original type along without wrapping it for nought.) Currently, when taking a callable type, by an unrestricted template, or > when storing it > using the auto keyword, one looses absolutely all information about the > type, > This bit makes absolutely no sense. The information about the type *is all there*. Nothing is lost. In fact, that is the sole reason the implementation given works. `auto` is not dynamic typing. Semantically, `auto x = get_a_T();` it loses as much information as `T x = get_a_T();` The proposal light touches on polymorphic callables near the end, and shows a bunch of clearly useless examples of usage. If I know the types of the parameters, I don't need a type trait to tell me the arity. Even if I only know the types as a variadic pack, I can ask `sizeof...` for the arity. On Wednesday, December 4, 2013 4:12:43 AM UTC+1, Emil 'Skeen' Madsen wrote: > > This thread, is for discussion of the second revision of the paper posted > at; > A proposal to add lambda/function traits to the STL > > The proposal is about adding traits, to query a callable type's attributes > (return and argument type(s), amongst others), at compile time. > > A questions to open the discussion; > * With C++14 we are getting templated constexpr variables, should these be > used instead of `std::integral_constant`? > > Currently I'm considering these two alternatives; > > template > struct arity_integral : std::integral_constant > { > }; > > template > constexpr size_t arity = ... > > And currently traits are implemented using the first approach, however > this yields this usage scenario; > > size_t arity_old = std::arity_integral::value; > size_t arity_new = std::arity; > > I think going with the old approach, to be consistent with type_traits, > however I actually wanted > to know what people think about the alternative, and possibly providing > both. > > Anyhow, have a look, > I'm open to all kinds of criticism and feedback :) > -- --- 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_4544_16006054.1386152595860 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are several things that irk me here, so I'll just li= st them in order. For qualification I am on the camp that things this kind = of thing is nigh-useless and mostly abuseful. There are very few cases wher= e one really needs to obtain such information, and in those cases this prop= osal is very limited because we haven't been in a world of monomorphic call= ables in a long time and with C++14 the relevance of that world is about to= decrease drastically. We need different tools (I'd like: a Callable concep= t thingy, and for the niche scenarios some overload introspection thingy).<= br>
That said, let's go through it.

The document claims that "the= interface design is chosen to match the type_traits library", but the `typ= e_traits` library doesn't use template variables.

However, there are times, in which= we cannot provide a truly generic solution, and
where we are forced to = take type information into account, and hence we need a generic
way to q= uery information about the instantiated type(s).

I= have written a lot of generic code that uses callable objects and I never = needed this, so I got curious about the use cases (i.e. that "I must be mis= sing something" feeling). However the proposal document does not provide an= example. It provides an artificial example of usage, but that isn't convin= cing because "You can use it to demonstrate the feature featured in this pr= oposal" is not an interesting example.
(The example irks me particularly= because `make_stdfunction` seems quite silly to me; to me it feels a bit l= ike a `make_vector(T x) { return vector<T>{x}; }`, with the differenc= e that the vector will have a richer interface than T, but std::function do= es not have a richer interface than the source. One can just pass the origi= nal type along without wrapping it for nought.)

Currently, when taking a callable typ= e, by an unrestricted template, or when storing it
using the auto keywor= d, one looses absolutely all information about the type,

This bit makes absolutely no sense. The information about the type *= is all there*. Nothing is lost. In fact, that is the sole reason the implem= entation given works. `auto` is not dynamic typing. Semantically, `auto x = =3D get_a_T();` it loses as much information as `T x =3D get_a_T();`
The proposal light touches on polymorphic callables near the end, and show= s a bunch of clearly useless examples of usage. If I know the types of the = parameters, I don't need a type trait to tell me the arity. Even if I only = know the types as a variadic pack, I can ask `sizeof...` for the arity.
=

On Wednesday, December 4, 2013 4:12:43 AM UTC+1, Emil 'Skee= n' Madsen wrote:

This thread, is for discussion of the second revision of the paper po= sted at;
    A proposal to add lambda/function traits to the STL

The prop= osal is about adding traits, to query a callable type's attributes (return = and argument type(s), amongst others), at compile time.

A questions t= o open the discussion;
* With C++14 we are getting templated constexpr v= ariables, should these be used instead of `std::integral_constant`?

C= urrently I'm considering these two alternatives;
<code>
templat= e<typename Callable, typename... Args>
struct arity_integral : std= ::integral_constant<size_t, ...>
{
};

template<typenam= e Callable, typename... Args>
constexpr size_t arity =3D ...
</= code>
And currently traits are implemented using the first approach, = however this yields this usage scenario;
<code>
size_t arity_ol= d =3D std::arity_integral<decltype(lambda)>::value;
size_t ar= ity_new =3D std::arity<decltype(lambda)>;
</code>
I think= going with the old approach, to be consistent with type_traits, however I = actually wanted
to know what people think about the alternative, and pos= sibly providing both.

Anyhow, have a look,
I'm open to all kinds o= f criticism and feedback :)

--
 
---
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-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/<= /a>.
------=_Part_4544_16006054.1386152595860-- .