220 35963 <7eb526d4-c557-443c-a7d5-235dc8e44926@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Make aliased templates first class citizens Date: Sun, 17 Dec 2017 17:18:29 -0800 (PST) Lines: 350 Approved: news@gmane.org Message-ID: <7eb526d4-c557-443c-a7d5-235dc8e44926@isocpp.org> References: <8e4dd67b-e929-4f83-8f68-4a7ebd20a4e3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5969_1092391641.1513559909252" X-Trace: blaine.gmane.org 1513559794 824 195.159.176.226 (18 Dec 2017 01:16:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Dec 2017 01:16:34 +0000 (UTC) Cc: adrian.hawryluk@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBZVO3TIQKGQERAJD23Q@isocpp.org Mon Dec 18 02:16:30 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQk2f-0008I8-N2 for gclcip-std-proposals@m.gmane.org; Mon, 18 Dec 2017 02:16:30 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id j7sf2055311vke.17 for ; Sun, 17 Dec 2017 17:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=X8pHL3l8C0yv4a2Kxv5v8yiWpP0hD0DmgLRkX2bXmOk=; b=aQsaDi7e8bStkKiMt45vq1RxEImqLhWL6FRYKU7Yk0O8+bqMiFRVpm1shT8znMI1fW oXffEmaRiWTEHyxytjP6hnN2Fd6tH81oDolv9UCk1lPseVEWBbBfEkQwVq5ZBIi9AUo1 +H8gB6h2y5N3kU2s+jW5iA2MN1C2et9HjeAWOEeHcMNwgd34b5R/YfxZVfrj+miePcVH GiRQEvqtrEHBR15hqpwEt1fYksUlVNnR6jvxC1s+Q7mA3p0XeaxTecNvV8V2NwW3TrGc nznquXOhZ99IvJrUlUPjs2uEPd4SIEL8a9jBgXBS0wlElEv5fkeZofUtX9wyJBw7f4hb aSZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=X8pHL3l8C0yv4a2Kxv5v8yiWpP0hD0DmgLRkX2bXmOk=; b=W8vhW7nTObagp3/Zkiz7jhUhU3PSK3i8QR92q9GW5381WeRWkSo3o6+/xzcgYdvWYQ h87LD9h+l0Gd4p2rLLnVT8QbGiq9DR+QlK1Sn6KCMYdfl8m5j5XW0LdsBJbmYZ7SDeU2 UKYJGWsKSgUat+GiKdGQuFIecBkcQiJrjayKwaBhj62vRC0E+XPnR19y7JBk8VHQtNng Ynxje8g8grKNI4y4T9qvdOqmANS8kBb8FzdGy8Zbh7GDIUTysEqnTFZztqwhI3vWvzW4 /slW66J3NhZ8Xu8XHjg3SzNjqVGd691UlrM1/6urE1a73I2GxZLLI/4VM/EPesH+Ek7z l9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=X8pHL3l8C0yv4a2Kxv5v8yiWpP0hD0DmgLRkX2bXmOk=; b=ty4ffEW4EycecYSCJmi/i1UcdQh3ipCs46At6VQyFEGdiSJUG1Y7wRbYJSUiIqf+XQ k8D2HLFMXpR5gv8SKwpI4nKPdLPjn3kAE+Rt1td37LhL/ZaB94aVneUquF8MLXCnWLUR x72djRcYhycyCebmgvGaaIPRzqfhwakNzG/gm7dmglp5Eu7/S64ZfkVZu7oY0dDoqeCo R+XhBfaPG6Jw7QK6Kzz48BkvBYjf0gxCvcFtyQRkKMuFuGyJqLRF7A+Qq42+PlRW6E5B iDLwTx2q/9+ZW0QGBggqfA0Lwib76qpoS+ue/2QRu2t5UTiYmFfdJzbOHuKVQyxgtIDv MlGw== X-Gm-Message-State: AKGB3mLf2Z1uwwWdXdjlPr0P/TDfAHunxBcFfYnhhLRcdD3qb1qlD1Ml eQLijhtwNvrzD/i0Oh9LWg38KQ== X-Google-Smtp-Source: ACJfBoumbXZ08foleOrAARpWVkaOLPjWhRTwYiJsIWxqJwyiwbjdTmz/EOyH3e2gf++Tr6f+bDc0tA== X-Received: by 10.176.10.135 with SMTP id d7mr1766897uak.105.1513559911723; Sun, 17 Dec 2017 17:18:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.36.36 with SMTP id 33ls3994120uaq.2.gmail; Sun, 17 Dec 2017 17:18:30 -0800 (PST) X-Received: by 10.31.2.144 with SMTP id 138mr1822116vkc.5.1513559909961; Sun, 17 Dec 2017 17:18:29 -0800 (PST) In-Reply-To: <8e4dd67b-e929-4f83-8f68-4a7ebd20a4e3@isocpp.org> X-Original-Sender: inkwizytoryankes@gmail.com 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:35963 Archived-At: ------=_Part_5969_1092391641.1513559909252 Content-Type: multipart/alternative; boundary="----=_Part_5970_2088822440.1513559909253" ------=_Part_5970_2088822440.1513559909253 Content-Type: text/plain; charset="UTF-8" On Monday, December 18, 2017 at 1:21:12 AM UTC+1, adrian....@gmail.com wrote: > > Templates are wonderful idea, but if I need to make a template with > partially defined parameters, this becomes problematic, requireing that an > intermediate class is made with a template in it. Because the template > then becomes a dependent type, we then have to declare the word template > before it's name if you pass it, which is ugly and sometimes difficult to > track down what is wrong when you get the syntax incorrect. > > Complete template aliasing is available in the language like this: > > template > using my_is_convertable = std::is_convertable; > > I propose that partial template aliasing also be allowed, which would > allow the template be broken up in to 2 or more sub-templates. > > For example, say I have a find meta-algorithm, which will have a value > that is true if any of OP::value... are true or false otherwise. I > will only declare it here for brevity. > > template class OP, typename...Ts> > struct find; > > It is defined as a unary template operator to apply the DRY principal. > Now if I want to use this on a binary template operator, then I would need > to bind the parameter. If known ahead of time, it would become: > > template > using my_is_convertable = std::is_convertable; > > and would be used like so: > > find::value > > However, if it's not known ahead of time what to bind the parameter to I > would have to use an class template with a embded template alias in it like > this: > > template > struct my_is_convertable > { > template > using ttype = std::is_convertable; > }; > > And use it like this: > > find::template ttype, float, int double>::value > > I propose that instead we use this syntax to define partial template > aliasing: > > template > template > using is_convertable = std::is_convertable; > > find, float, int double>::value > > This would also make this valid: > > my_is_convertable::value > > Which should be fine. > > Pros: > > Verbosity is lowered, no more need for referring to an embedded template > is required which follows that the need for the template keyword is also > removed, all of which reducing noise. Also it would not break anything in > the wild. This would also mostly remove the need for tbind, except in > cases where symbol leakage is not wanted in the enclosing scope. > > Cons: > > Developers would need to get used to the syntax. Nothing too crazy > though. > > What is everyone's opinion on this? > > Right now I see only one problem with this: template using B = typename A::template template temp<1><2>; //or template using C = template A::template temp<1>; //this return template not type, this could be problematic when C++20 remove options for different `using` //or template using D = template template A::temp; You will probably need something like this to allow proper handle of `<` and `>` by compiler in dependent context. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7eb526d4-c557-443c-a7d5-235dc8e44926%40isocpp.org. ------=_Part_5970_2088822440.1513559909253 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, December 18, 2017 at 1:21:12 AM UTC+1, = adrian....@gmail.com wrote:
Templates are wonderful idea, but if I need to make a te= mplate with partially defined parameters, this becomes problematic, require= ing that an intermediate class is made with a template in it.=C2=A0 Because= the template then becomes a dependent type, we then have to declare the wo= rd template before it's name if you pass it, which is ugly and sometime= s difficult to track down what is wrong when you get the syntax incorrect.<= /div>

Complete template aliasing is available in the lan= guage like this:

=C2=A0<= span style=3D"color:#008">template <typename<= /span> FROM, typename= TO>=
=C2=A0using my_is_convertable =3D std::is_convertable<FROM, TO= >;

I propose that partial template aliasing also be allowed, which would al= low the template be broken up in to 2 or more sub-templates.

=
For example, say I have a find meta-algorithm, which will have a= value that is true if any of = OP<Ts>::value... are tru= e or false otherwise.=C2=A0 I will only declare it here for brevity.
<= div>
=
=C2=A0template <typename <typename> class OP, typename...Ts>
=C2=A0struct find= ;

It is defined as a unary template oper= ator to apply the DRY principal.=C2=A0 Now if I want to use this on a binar= y template operator, then I would need to bind the parameter.=C2=A0 If know= n ahead of time, it would become:

=C2=A0template <typename TO>
=C2=A0using my_is_convertabl= e =3D s= td::is_= convertable<int, TO>;

and would be used like so:

=C2=A0find<my_is_convertable,= float<= /span>, int, double>::value
<= /span>

However, if it's not known= ahead of time what to bind the parameter to I would have to use an class t= emplate with a embded template alias in it like this:

<= div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187= );border-style:solid;border-width:1px;word-wrap:break-word">
=C2=A0template <typename FROM= >=C2=A0struct my_is_convertable
=C2=A0{
=C2=A0 =C2=A0template <typename TO>
=C2=A0 =C2=A0using<= span style=3D"color:#000"> ttype =3D std::is_convertable<FROM, TO&= gt;;
=C2=A0};

And use it like this:

= =C2=A0find<my_is_convertable<int>::templa= te ttype, floa= t, int = double>::value
I propose that instead we use this syntax to define partial template alias= ing:

=C2=A0template <typename TO>
=C2=A0template= <typename = FROM>
=C2=A0using is_convertable =3D std::is_convertable<TO,= FROM>;

=C2=A0find<my_is_convertable<int>,<= span style=3D"color:#000"> float, int double>::value

Th= is would also make this valid:

= =C2=A0my_is_convertable<int><int= >::<= wbr>value

Which should be = fine.

Pros:

Verbosity is = lowered, no more need for referring to an embedded template is required whi= ch follows that the need for the template keyword is also removed, all of w= hich reducing noise.=C2=A0 Also it would not break anything in the wild.=C2= =A0 This would also mostly remove the need for tbind, except in cases where symbol leakage is not wanted = in the enclosing scope.=C2=A0=C2=A0

Cons:

Developers would need to get used to the syntax.=C2=A0 Not= hing too crazy though.=C2=A0=C2=A0

What is everyon= e's opinion on this?

=C2=A0=
Right now I see only one problem with this:
template<typename A>
using B =3D= typename<= /span> A::template template temp<1><2>;=
//or
<= span style=3D"color: #008;" class=3D"styled-by-prettify">template<typename A>
using C =3D template = A::= template temp<1>; //this return template not type, this could be prob= lematic when C++20 remove options for different `using`
//or
template<typename A>
u= sing D =3D template template A::temp;
You will probably need something like th= is to allow proper handle of `<` and `>` by compiler in dependent con= text.

--
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/7eb526d4-c557-443c-a7d5-235dc8e44926= %40isocpp.org.
------=_Part_5970_2088822440.1513559909253-- ------=_Part_5969_1092391641.1513559909252-- .