220 35962 <8e4dd67b-e929-4f83-8f68-4a7ebd20a4e3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: adrian.hawryluk@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Make aliased templates first class citizens Date: Sun, 17 Dec 2017 16:21:12 -0800 (PST) Lines: 339 Approved: news@gmane.org Message-ID: <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_15117_1155179396.1513556472507" X-Trace: blaine.gmane.org 1513556359 13798 195.159.176.226 (18 Dec 2017 00:19:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Dec 2017 00:19:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCULLOGNUQIRB6UT3TIQKGQEBTCVP3A@isocpp.org Mon Dec 18 01:19:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQj9G-0003Av-5S for gclcip-std-proposals@m.gmane.org; Mon, 18 Dec 2017 01:19:14 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id 107sf9053843uau.20 for ; Sun, 17 Dec 2017 16:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=T0GZaEbkwX56hyvM0FUj98rBdoVKtV34ts2oRUYGIHY=; b=zTs92sfQVy9YUQMvw02dewPlRBboD/ROrM+SGj7ycod9u/PI8YWLcIhTaPrkDC1IHW e+Rgpp3UEmH43QSfVRo7zvX7v17dsN4X6LcINbsIEoS9NTR91khEkI0vgTToRnxTnSuF XCls/Gx031iuTzyNhm3glPFarQm/o1xTu1FRPUhGZyWRzP7Rz2ZjtVuFZ+Kake0cJAHJ BxRKySWu0mM1ga1/lmPbYtsSNR0LCQusOIrRzldtg2xy3V/26MJjAk7DnMGb0ey4c3Qs 5nwCXkNVrChTz214EKMR60BbbovrhRxn1cqr71tbuWR/8SaBxLGyo51Akm5rzL2UeJ2O BnPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=T0GZaEbkwX56hyvM0FUj98rBdoVKtV34ts2oRUYGIHY=; b=UdGa2v2aEagmyaJ9kOK8flBvto0abCB1EtNLHf3NFIRQvbtyum5zguxIiY8NTz9PT7 CqG90EM4I2/91gpVPKRyZXuF760SMrHK9U0N6jOnJYAGvN4Uh5UDbl8I5wDDodEPgf1l 6aionFU/o0ansVtLp03ptSzQzIQ1fAs8GqLjKdFKQ8hCD6TX2/XwWF0JUsJAwWP1kFuX mvrPe7+iryrTGDL/tNH3WQCo+Xtj8FkAo4kfml9PyXZ3TNH4p7Hd/du6gdO2+eui6djB kLcZMBkmOaXg7KJhc6aIfK4XuIn7VmXIq6aV2vaJGnVvQDBOU//4YqDxN5Ol/wXW6K2J mo9A== 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:message-id: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=T0GZaEbkwX56hyvM0FUj98rBdoVKtV34ts2oRUYGIHY=; b=QXqZR2kkUYqoAbw6pACf3sKbTwEH0g8ME23iWSbZZQl5SjwkY0vV4I+OG4SAunNxAs lBHB19LN7P70ILh3NtjJd5AC/1kYNdw4SoHSHr0fjIxzL8a9cEt2eXmEbVRjDpkgOvVY LaRpK1UsaMrLBqgzBsahaD0kehbaoezLAcBHvY8eYC6isvGQGAPxZhr9q8QgTHCOLrIn WecM+M0RnV4d+9Ko+3j8DUlanex48Wxb9/zspHGvSyTbq+iA0DaexqjbL+lQVBmyDpYc b5jnmj63lWaUHBRVGjzVio+x7OgEnFX8BwUqwzYzrLCP6+VrPHa6xWERY1ajRLIoxGK0 OUwQ== X-Gm-Message-State: AKGB3mLB9kqHHdsrBHfB8u82X7YRGLeIf5vQn4j4VsRXWqQR6bN7a5E/ mWl/97jdGLkyxVxy1yz1Frc1Zw== X-Google-Smtp-Source: ACJfBoudSTTCqY3re2SGknSq31DFRHdJILAV86efN9YBe7v6mlbZjyZkWjOVYYOvGecBIqG/Ypinow== X-Received: by 10.159.55.107 with SMTP id a40mr2972501uae.53.1513556475982; Sun, 17 Dec 2017 16:21:15 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.242.79 with SMTP id q76ls3882526vkh.12.gmail; Sun, 17 Dec 2017 16:21:14 -0800 (PST) X-Received: by 10.31.165.202 with SMTP id o193mr482617vke.9.1513556473079; Sun, 17 Dec 2017 16:21:13 -0800 (PST) X-Original-Sender: adrian.hawryluk@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:35962 Archived-At: ------=_Part_15117_1155179396.1513556472507 Content-Type: multipart/alternative; boundary="----=_Part_15118_1731546777.1513556472508" ------=_Part_15118_1731546777.1513556472508 Content-Type: text/plain; charset="UTF-8" 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? -- 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/8e4dd67b-e929-4f83-8f68-4a7ebd20a4e3%40isocpp.org. ------=_Part_15118_1731546777.1513556472508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Templates are wonderful idea, but if I need to make a= template with partially defined parameters, this becomes problematic, requ= ireing that an intermediate class is made with a template in it.=C2=A0 Beca= use 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 somet= imes difficult to track down what is wrong when you get the syntax incorrec= t.

Complete template aliasing is available in the = language like this:

=C2=A0template <typename FROM, typename<= span style=3D"color: #000;" class=3D"styled-by-prettify"> TO>
=C2=A0using my_is_convertable =3D std::is_convertable<FROM, TO>;

I propose that partia= l template aliasing also be allowed, which would allow the template be brok= en 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 true or false otherwise.=C2= =A0 I will only declare it here for brevity.

=C2=A0template <typename <typename> class OP, typename...Ts>
=C2=A0struct find;

I= t is defined as a unary template operator to apply the DRY principal.=C2=A0= Now if I want to use this on a binary template operator, then I would need= to bind the parameter.=C2=A0 If known ahead of time, it would become:

=C2=A0= template <= /span><= typename TO>
=C2=A0using my_is_convertable =3D std::is_convertable<int, TO>;

and would be used like = so:

<= div class=3D"subprettyprint">=C2=A0find<my_is_convertable, float= , int, double>::value

Howe= ver, if it's not known ahead of time what to bind the parameter to I wo= uld have to use an class template with a embded template alias in it like t= his:

=
=C2=A0template &l= t;typename= FROM>
=C2=A0struct my_is_convertable
=C2= =A0{
=C2=A0 =C2= =A0templat= e <= span style=3D"color: #660;" class=3D"styled-by-prettify"><typename TO>
=C2=A0 =C2=A0using ttype =3D std::is_convertable<FROM, = TO>;
=C2=A0};

And use it like this:

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

I propose that instead we use this syntax to define partial= template aliasing:

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

= =C2=A0find= <my_is_= convertable<int>, float, int double>::value

This wou= ld also make this valid:

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

Which should be fine.

Pros:

Verbosity is lowered, no more need for re= ferring to an embedded template is required which follows that the need for= the template keyword is also removed, all of which reducing noise.=C2=A0 A= lso it would not break anything in the wild.=C2=A0 This would also mostly r= emove the need for tbind, exce= pt in cases where symbol leakage is not wanted in the enclosing scope.=C2= =A0=C2=A0

Cons:

Developer= s would need to get used to the syntax.=C2=A0 Nothing too crazy though.=C2= =A0=C2=A0

What is everyone's opinion on this?<= /div>

--
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/8e4dd67b-e929-4f83-8f68-4a7ebd20a4e3= %40isocpp.org.
------=_Part_15118_1731546777.1513556472508-- ------=_Part_15117_1155179396.1513556472507-- .