220 16704 article Path: news.gmane.org!not-for-mail From: Faisal Vali Newsgroups: gmane.comp.lang.c++.isocpp.proposals,gmane.comp.lang.c++.isocpp.general Subject: Re: An implementation of enhanced auto deduction and abbreviated template syntax using Clang Date: Wed, 4 Mar 2015 06:45:02 -0600 Lines: 282 Approved: news@gmane.org Message-ID: References: <7c7d06ea-1e25-4720-9486-ec068b514ea6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1425473110 20583 80.91.229.3 (4 Mar 2015 12:45:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 12:45:10 +0000 (UTC) Cc: std-proposals@isocpp.org, "std-discussion@isocpp.org" , "c++std-core@accu.org" To: "Arthur O'Dwyer" Original-X-From: std-proposals+bncBDDKRIXX5YARBTX43OTQKGQEKPSTEVA@isocpp.org Wed Mar 04 13:45:06 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YT8fg-0003XR-JX for gclcip-std-proposals@m.gmane.org; Wed, 04 Mar 2015 13:45:04 +0100 Original-Received: by igbhl2 with SMTP id hl2sf190871143igb.1 for ; Wed, 04 Mar 2015 04:45:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=lvthGGTW2UlMNHGdvooK9Zx2pll6b+Vf1wW+AH+M0LY=; b=QOoH2YYMAGPSZz0fukfbDGMhHDvkugsdSwWMHMFH4+vfWV2ZMBffArF4M/j6jqE9kE gSt+8i6FAwYtKBNLAXtNOR6tUbbFDJoO+WronIMMF1mbvy7bo6numZrBkMCNRAZt0NzJ IL7DYkEE69qlL7TsgnTj8Sb7zFd+nxjSpf2MW6tuVTEAvfXOfbotC2go6UGSvZE41J5p h8icxPWwHEKgtq05LI7d2Q4+hqKGbqGLaBY+XlBRwC5BOLU3FxGlFLWvIKQvCknZM8z7 TtEz4xoYcri3RkdVhZI6wtPZkntxTuFbuQogN9kHZBWstTa+f62YTnDePSU8o3pvjZ48 +bpg== X-Gm-Message-State: ALoCoQlZGPR+s3wKXVU2K7DfQhzQROMn50WeM5pJ4vuHU99HYn1FX9BwLWmgcGuYxaUIiheAy7xu X-Received: by 10.182.246.67 with SMTP id xu3mr4710867obc.18.1425473103521; Wed, 04 Mar 2015 04:45:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.19.17 with SMTP id b17ls533172ioj.35.gmail; Wed, 04 Mar 2015 04:45:02 -0800 (PST) X-Received: by 10.107.131.83 with SMTP id f80mr10754821iod.50.1425473102532; Wed, 04 Mar 2015 04:45:02 -0800 (PST) Original-Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com. [2607:f8b0:4001:c05::22e]) by mx.google.com with ESMTPS id vt2si4819808igc.50.2015.03.04.04.45.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 04:45:02 -0800 (PST) Received-SPF: pass (google.com: domain of faisalv@gmail.com designates 2607:f8b0:4001:c05::22e as permitted sender) client-ip=2607:f8b0:4001:c05::22e; Original-Received: by igjz20 with SMTP id z20so36186692igj.4; Wed, 04 Mar 2015 04:45:02 -0800 (PST) X-Received: by 10.50.20.228 with SMTP id q4mr10528492ige.1.1425473102356; Wed, 04 Mar 2015 04:45:02 -0800 (PST) Original-Received: by 10.50.17.195 with HTTP; Wed, 4 Mar 2015 04:45:02 -0800 (PST) In-Reply-To: <7c7d06ea-1e25-4720-9486-ec068b514ea6@isocpp.org> X-Original-Sender: faisalv@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of faisalv@gmail.com designates 2607:f8b0:4001:c05::22e as permitted sender) smtp.mail=faisalv@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:16704 gmane.comp.lang.c++.isocpp.general:4955 Archived-At: On Tue, Mar 3, 2015 at 11:36 PM, Arthur O'Dwyer wrote: > On Tuesday, March 3, 2015 at 6:39:49 PM UTC-8, faisalv wrote: >> >> In the hopes of soliciting constructive feedback, if anyone has the >> time or the interest to play with a patched up Clang that implements >> enhanced auto deduction & abbreviated template syntax from the >> concepts ts, here it is: >> >> https://github.com/faisalv/clang/tree/enhanced-auto-c%2B%2B1z . > > > That's very very cool =E2=80=94 at least the "abbreviated template syntax= " half! ;) > Is it possible for you to separate out the "abbreviated template syntax" > feature from the "enhanced auto detection" feature, into two separate > patches that could be looked at and/or adopted individually? > > Now that we have generic lambdas (in C++14), I'm looking forward to havin= g > "generic functions" (i.e., abbreviated template syntax) sooner rather tha= n > later. > > // C++14: Create a lambda object with a template member operator() > auto f =3D [](auto x, auto y) { return x + y; }; > > // C++1z: Create a template function directly > auto f(auto x, auto y) { return x + y; } > > >> 1) Enhanced-Auto Deduction: >> >> pair f() { return make_pair([] { }, [] { }); } >> vector v =3D vector(); > > > I don't see the use-case for this feature. Why would I write > > vector v =3D vector(); > > when it's less typing and less noise to just write > > auto v =3D vector(); > I generally agree with the above statement - but there are some who have argued that it can improve readability - and I see their point too. > ? Also, as you noted in technicality (d), it's impossible to support > "enhanced deduction" for type aliases. I don't like the asymmetry this > creates between "class types" and "typedef types". Here are a collection= of > "enhanced" cases where deduction fails (in some cases, MUST fail). > > template using identity1 =3D T; > identity1 id1 =3D 42; > template struct identity2 { using type =3D T; }; > identity2::type id2 =3D 42; > template struct int3 { using type =3D int; }; > int3::type id3 =3D 42; > template using int4 =3D int; > int4 id4 =3D 42; > > I'm mostly concerned with the fact that you're making identity1 fai= l, > while vector succeeds. Sorry, I was unclear - identity1 id1 =3D 42 is the only one of your examples that works. What does not work is: if you invent a template parameter for each placeholder in your declaration - but while doing template argument deduction thru a function call, if any template parameters are left undeduced - that's an error (even if the alias does not use the template parameter after desugarring). Consider: template void f(int4 id4); f(42); // Error. > > Here's a use-case I could maybe get behind: > > vector vec =3D { 1, 2, 3 }; // creates a vector of int > > except that (correct me if I'm wrong) your patch doesn't support that > use-case. And I'm not sure how it could. > No - since template argument deduction for function calls does not support = that. >> >> 2) Abbreviated Template Syntax: >> void f(auto) <=3D> template void f(T); > > > THIS is the very very awesome part. I am super excited about this feature > finally coming to a compiler near me! Hah - our gcc friends have had this for ages :) - I've submitted a patch for clang's review - but if history is any indication - the review cycles (my latencies included) can take months. > >> A few, perhaps not so obvious or interesting, technicalities: >> >> a) The equivalence of templates when it comes to trailing return >> types in function pointer parameters is based on the order of the >> 'auto' that signifies a placeholder, not just the appearance of an >> auto in the declaration-specifier of a parameter: >> >> template void f( R(P) ); // #1 >> template void f( R(P) ); // #2 (order of >> templ-params flipped) >> >> template void f( auto (P)->R); // equivalent to >> #1, not abbreviated. > > > How many of these weirdnesses vanish if you get rid of "enhanced auto > deduction"? None - this has nothing to do with initializer deduction - only trailing return type syntax. > Clang 3.7.0 doesn't currently allow trailing return types on C++14 generi= c > lambda parameters, which IMHO is a feature (in that allowing them leads t= o > the grotesqueries you mention) but I'm pretty sure from the Standard's PO= V > is a bug. (Contrariwise, I think GCC 5.0.0 is *too* permissive. But in > neither case am I sure exactly what's allowed by the Standard.) > No one is sure (except for maybe 10 or so kingsmen* that round table it ~twice a year) exactly what's allowed by the standard ;) (*) gender neutrality invoked > http://melpon.org/wandbox/permlink/QMQXHNsBmwVJbxM0 > int one(int (*f)(int)) { return f(42); } // C++03 > int two(auto (*f)(int) -> int) { return f(42); } // C++11 > int three(auto (*f)(int)) { return f(42); } // never > int four(auto (*f)(int) -> auto) { return f(42); } // never > int five(int (*f)(auto)) { return f(42); } // never > int six(int f(int)) { return f(42); } // C++03 (takes a function pointer= ) > int seven(int f(auto)) { return f(42); } // never > > > auto bone =3D [](int (*f)(int)) { return f(42); }; // C++11 > auto btwo =3D [](auto (*f)(int) -> int) { return f(42); }; // never > auto bthree =3D [](auto (*f)(int)) { return f(42); }; // C++14 > auto bfour =3D [](auto (*f)(int) -> auto) { return f(42); }; // never > auto bfive =3D [](int (*f)(auto)) { return f(42); }; // never > auto bsix =3D [](int f(int)) { return f(42); }; // C++11 (takes a functi= on > pointer) > auto bseven =3D [](int f(auto)) { return f(42); }; // never > > >> >> void f(auto(auto)); // equivalent to #1 > > > IMHO, this should be disallowed. It deduces a function type for the > parameter, and then "decays" that type to a function pointer, in the same > way that parameters of array type "decay" to pointers. This was inherited > from C, is super confusing, and in an age of generic lambda functors real= ly > deserves to be put to bed. I hear you - but it is easier to write test cases without the extra syntax to denote a ptr or ref. > > auto f(auto ga(auto)) { return ga("hello world"); } > auto g(auto xa) { puts(xa); } > int main() { f(g); } > > Today, even though it looks like ga and g have the same type, they don't!= g > is a function template, and ga is a pointer to a function of unspecified > type. > The idiomatically correct signature for f IMHO would be > > auto f(auto *ga) { return ga("hello world"); } > > >> b) variadic auto >> Once an ellipsis is seen as part of the declarator, all contained >> auto placeholders get transformed into parameter packs. >> void f(auto (*...)(auto) -> std::tuple> auto>...>); >> Note there are 4 deducible template parameter packs above. > > > Do I understand correctly that the above is exactly equivalent to > > template > void f1(std::tuple...> (*...args)(D)); > > void f2(std::tuple...> (*...args)(auto)); > > where f1 uses C++11 syntax and f2 uses only "abbreviated template" syntax= ? > Yes. >> c) multi abbreviated template declarations >> void f(auto), g(auto); >> are allowed - the above declares two function templates. > > > That's not allowed for non-abbreviated templates, and again I don't see a > use-case for it. What's a case where I would want to chain together funct= ion > declarations like that? Again, that seems like cruft inherited from C tha= t > could easily be dumped at least for new syntax. > I don't think I care much either way - but I don't think this forbidden by the TS. > You don't mention this as a pitfall, but looking at your test cases I > observed that > > auto foo =3D 42; // foo is definitely an int > void bar(auto baz =3D 42); // baz is NOT an int; it's of some deduce= d > type. > // The initializer 42 is coerced to that ty= pe > if necessary. Yes - I can see the potential for confusion - but perhaps if you mentally replace an 'auto' in a function declaration with a template type parameter, and in an initializer deduction with a function call with the initializer, perhaps the confusion can be minimized - but I agree, it is unfortunate that such asymmetry exists. > > Consider the following progression: > > template auto one(X x, Y y=3D1) { return x+y; }; = // > legal C++14 > template auto two(X x, Y y=3D1) { return x+y; }; // > invalid, and rightly so > auto three =3D [](auto x, auto y=3D1) { return x+y; }; // invalid, but I= claim > it has an obvious meaning that should be standardized > auto four(auto x, auto y=3D1) { return x+y; }; // invalid?? with your pa= tch, > but I claim it has an obvious meaning > int main() { one(1); two(2); three(3); four(4); } > > I know this has been a massive and scattered array of potshots, but I hop= e > you find some of it interesting and/or useful. :) > > =E2=80=93Arthur I certainly did - Thanks! --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. .