220 16723 <66d5a2c4-5572-413c-adc0-b6afd7f5ff01@isocpp.org> article Path: news.gmane.org!not-for-mail From: Scott Prager Newsgroups: gmane.comp.lang.c++.isocpp.general,gmane.comp.lang.c++.isocpp.proposals Subject: Re: An implementation of enhanced auto deduction and abbreviated template syntax using Clang Date: Wed, 4 Mar 2015 08:52:50 -0800 (PST) Lines: 337 Approved: news@gmane.org Message-ID: <66d5a2c4-5572-413c-adc0-b6afd7f5ff01@isocpp.org> References: Reply-To: std-discussion@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_337_334394783.1425487970241" X-Trace: ger.gmane.org 1425487981 23261 80.91.229.3 (4 Mar 2015 16:53:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 16:53:01 +0000 (UTC) Cc: std-discussion@isocpp.org, c++std-core@accu.org, faisalv@gmail.com To: std-proposals@isocpp.org Original-X-From: std-discussion+bncBCU6PTE6UUGBBYXQ3STQKGQEPISOWRY@isocpp.org Wed Mar 04 17:52:55 2015 Return-path: Envelope-to: gclcig-std-discussion@m.gmane.org Original-Received: from mail-qa0-f70.google.com ([209.85.216.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTCXU-0002i2-1Y for gclcig-std-discussion@m.gmane.org; Wed, 04 Mar 2015 17:52:52 +0100 Original-Received: by mail-qa0-f70.google.com with SMTP id bm13sf143967373qab.1 for ; Wed, 04 Mar 2015 08:52:51 -0800 (PST) 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type: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=e+UU1XfbI7N/GJJ3XfFAqpHZEKd8UXgUveveu9cxxio=; b=NS99cXKt6H/fJqhnGt7mbP1SjrNRhCHzVYFkQI19movYp5lMv+Q6azkI0fUmrxPaEL UxbCf0N71kxVVinXesXHL9sz6RUBl485AneCWmFwfbgA5DJKLlwx8M5w24Vf/gX8MZE7 0QMBYn8K/tfVYArhn0ZNOGSCep2XKlcf8Ho3Fd9vW01z2m0sI7DdHMjVKQy99q+OFaV2 iJGlMFtU+vb//zgTvs+kNP5rteiNjpSyXAC3IgZDRC72fI9JT0+xoSuYpOh+9aYNGOPA t3uEGAqAbCxr2Ec9ZMkXWSeJoqhPpmuk3CpHdKYn7Qq4eAkSMu0kWM57CjhA5FwR/5Km S5+A== X-Gm-Message-State: ALoCoQlGo0IRgzY3tZGrMU4nUKHAzxW79Cjsck5e3dCv6oVVJzIBds5a/qtZCEKynesZHtMBlXID X-Received: by 10.236.26.17 with SMTP id b17mr5423965yha.15.1425487971150; Wed, 04 Mar 2015 08:52:51 -0800 (PST) X-BeenThere: std-discussion@isocpp.org Original-Received: by 10.182.97.73 with SMTP id dy9ls267643obb.2.gmail; Wed, 04 Mar 2015 08:52:50 -0800 (PST) X-Received: by 10.182.249.102 with SMTP id yt6mr3760190obc.30.1425487970708; Wed, 04 Mar 2015 08:52:50 -0800 (PST) Original-Received: from mail-ob0-x23c.google.com (mail-ob0-x23c.google.com. [2607:f8b0:4003:c01::23c]) by mx.google.com with ESMTPS id o11si2408172obr.104.2015.03.04.08.52.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 08:52:50 -0800 (PST) Received-SPF: pass (google.com: domain of splinterofchaos@gmail.com designates 2607:f8b0:4003:c01::23c as permitted sender) client-ip=2607:f8b0:4003:c01::23c; Original-Received: by obbnt9 with SMTP id nt9so2305907obb.9 for ; Wed, 04 Mar 2015 08:52:50 -0800 (PST) X-Received: by 10.140.20.247 with SMTP id 110mr93141qgj.17.1425487970613; Wed, 04 Mar 2015 08:52:50 -0800 (PST) In-Reply-To: X-Original-Sender: SplinterOfChaos@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of splinterofchaos@gmail.com designates 2607:f8b0:4003:c01::23c as permitted sender) smtp.mail=splinterofchaos@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-discussion@isocpp.org; contact std-discussion+owners@isocpp.org List-ID: X-Google-Group-Id: 495566654649 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.general:4961 gmane.comp.lang.c++.isocpp.proposals:16723 Archived-At: ------=_Part_337_334394783.1425487970241 Content-Type: multipart/alternative; boundary="----=_Part_338_208413682.1425487970241" ------=_Part_338_208413682.1425487970241 Content-Type: text/plain; charset=UTF-8 Great stuff! No more writing *is_tuple* and *is_pair* functions to get SFINAE overloading. Although, a few things get me... (sorry, the code formatter isn't working for me right now) /// TEST *template* *void check(auto&& x) {* * static_assert(std::is_same::value);* *}* *template* *void check_copy(auto x) {* * static_assert(std::is_same::value);* *}* *//...* *int one;* *const int cone = 1;* *check(1);* *check(one);* *check(cone);* *check_copy(1);* *check_copy(one);* *check_copy(cone);* /// END TEST So, this check shows that when used as a function parameter, auto behaves very similarly to auto-initializing a variable. /// TEST *std::pair p = std::pair(1,1);* *std::pair q = std::pair(one,one);* *std::pair r = std::pair(1,1);* *template using P = std::pair&;* *check>(p);* *check>(q);* *check>(r);* /// END TEST This should that *auto* as a template parameter works consistently in that *tuple* would bind to a reference or rvlaue as well. I tested *auto& *and *auto&&* in this context as well, and they match against references and rvalues like template parameters. *void check_pair(std::pair) { static_assert(true); }* Particularly, this will only work if passed a *pair *with *std::move*... While it's entirely consistent with the rest of the language, it just seems odd that *auto* in one instance decays the type and in another acts like *decltype(auto)*. Not a complaint, just an observation. On Tuesday, March 3, 2015 at 9:39:49 PM UTC-5, 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 . > > The last line of the README file tells you the subversion revision of > LLVM to use. > > For examples of test cases that successfully compile, please refer to: > -- > https://github.com/faisalv/clang/blob/enhanced-auto-c%2B%2B1z/test/CXX/auto/cxx1z-auto-vars-generalized.cpp > -- > https://github.com/faisalv/clang/blob/enhanced-auto-c%2B%2B1z/test/CXX/auto/cxx1z-abbreviated-templates.cpp > > I would certainly appreciate the feedback! > > 1) Enhanced-Auto Deduction: > > pair f() { return make_pair([] { }, [] { }); } > vector v = vector(); > > 2) Abbreviated Template Syntax: > void f(auto) <=> template void f(T); > > > 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. > void f(auto(auto)); // equivalent to #1 > void f(auto (auto) -> auto); // equivalent to #2 > // the trailing return type > auto > // identifies a > template parameter > template void f(R(auto); // equivalent to #1 > template void f(auto(P)); // equivalent to #2 > > 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. > > c) multi abbreviated template declarations > void f(auto), g(auto); > are allowed - the above declares two function templates. > > d) template aliases desugar their types *after* each auto has been > identified as a placeholder (and so must be deduced) > > template using Int = int; > Int i = 3; // Is an error, auto must be deducible. > > e) generic lambda's as default arguments work with abbreviated template > syntax: > void f(int (*)(int) = [](auto a) { return a; }, auto b = decltype(b){}); > f(); // OK > > f) variable templates and enhanced auto deduction interact as expected: > template pair (*vfp)(auto...) = [](T t1, T* t2) > { return make_pair(t1, t2); }; > > Thanks! > Faisal Vali > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org. To post to this group, send email to std-discussion@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/. ------=_Part_338_208413682.1425487970241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great stuff! No more writing is_tuple and i= s_pair functions to get
SFINAE overloading. Although, a few th= ings get me...

(sorry, the code formatter isn't wo= rking for me right now)

/// TEST
template<class X>
void check(auto&& x) {
static_assert(std::is_same<decltype(x), X&&>::value);
}

template<class X= >
void check_copy(auto x) {
static_assert(std::i= s_same<decltype(x), X>::value);
}
<= br>
//...

int = one;
const int cone =3D 1;
check<int&g= t;(1);
check<int&>(one);
check&= lt;const int&>(cone);

check_c= opy<int>(1);
check_copy<int>(one);
check_copy<int>(cone);
/// END TEST

So, this check shows that when used as a function paramet= er,
auto behaves very similarly to auto-initializing a variable.<= /div>

/// TEST
std::pair<auto.= ...> p =3D std::pair<int, int>(1,1);
std::pair<= auto...> q =3D std::pair<int&, int&>(one,one);
std::pair<auto...> r =3D std::pair<int&&, int&&a= mp;>(1,1);

template<class X>= ; using P =3D std::pair<X,X>&;
check<P<int= >>(p);
check<P<int&>>(q);
<= div>check<P<int&&>>(r);
/// END = TEST

This should that auto as a = template parameter works consistently in
that tuple<T> would bind to a reference or rvlaue as well. I tested
= auto& and auto&& in this context as well, and t= hey match against
references and rvalues like template parameters= ..

void check_pair(std::pair<auto&&a= mp;, auto&&>) { static_assert(true); }

<= /div>
Particularly, this will only work if passed a pair<X&&a= mp;, Y&&> with std::move...
While it's enti= rely consistent with the rest of the language, it just
seems odd = that auto in one instance decays the type and in another
<= div>acts like decltype(auto). Not a complaint, just an observation.<= /div>


On Tuesday, March 3, 2015 at 9:39:49 PM UTC-5, fais= alv wrote:
In the hopes of soli= citing 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-aut= o-c%2B%2B1z .

The last line of the README file tells you the subversion revision of
LLVM to use.

For examples of test cases that successfully compile, please refer to:
 -- https://github.com/faisalv/clang/blob= /enhanced-auto-c%2B%2B1z/test/CXX/auto/cxx1z-auto-vars-generalize= d.cpp
 -- https://github.com/faisalv/clang/blob= /enhanced-auto-c%2B%2B1z/test/CXX/auto/cxx1z-abbreviated-template= s.cpp

I would certainly appreciate the feedback!

1) Enhanced-Auto Deduction:

 pair<auto...> f() { return make_pair([] { }, [] { }); }
 vector<auto> v =3D vector<int>();

2) Abbreviated Template Syntax:
void f(auto) <=3D> template<class T> void f(T);


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<class R, class P> void f( R(P) );  //= #1
    template<class P, class R> void f(  R(P) ); &n= bsp;// #2 (order of
templ-params flipped)

    template<class R, class P> void f( auto (P)->R);= // equivalent to
#1, not abbreviated.
    void f(auto(auto));  // equivalent to #1
    void f(auto (auto) -> auto); // equivalent to #2
                    &= nbsp;                    =      // the trailing return type auto
                    &= nbsp;                    =      // identifies a
template parameter
    template<class R> void f(R(auto); // equivalent to = #1
    template<class P> void f(auto(P)); // equivalent to= #2

b) variadic auto
    Once an ellipsis is seen as part of the declarator, all c= ontained
auto placeholders get transformed into parameter packs.
    void f(auto (*...)(auto) -> std::tuple<auto, std::p= air<auto, auto>...>);
 Note there are 4 deducible template parameter packs above.

c) multi abbreviated template declarations
   void f(auto), g(auto);
are allowed - the above declares two function templates.

d) template aliases desugar their types *after* each auto has been
identified as a placeholder (and so must be deduced)

    template<class T> using Int =3D int;
    Int<auto> i =3D 3; // Is an error, auto must be ded= ucible.

e) generic lambda's as default arguments work with abbreviated template= syntax:
  void f(int (*)(int) =3D [](auto a) { return a; }, auto b =3D dec= ltype(b){});
  f<float*>(); // OK

f) variable templates and enhanced auto deduction interact as expected:
    template<class T> pair<auto...> (*vfp)(auto..= ..) =3D [](T t1, T* t2)
{ return make_pair(t1, t2); };

Thanks!
Faisal Vali

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-discus= sion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion= /.
------=_Part_338_208413682.1425487970241-- ------=_Part_337_334394783.1425487970241-- .