220 30034 article Path: news.gmane.org!.POSTED!not-for-mail From: TONGARI J Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Make Typedef Great Again Date: Sun, 25 Dec 2016 23:38:47 -0800 (PST) Lines: 574 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1696_1228785115.1482737927673" X-Trace: blaine.gmane.org 1482737931 5402 195.159.176.226 (26 Dec 2016 07:38:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Dec 2016 07:38:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBBCESQPBQKGQETTVDX3Y@isocpp.org Mon Dec 26 08:38:47 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLPro-0000O5-OO for gclcip-std-proposals@m.gmane.org; Mon, 26 Dec 2016 08:38:45 +0100 Original-Received: by mail-io0-f198.google.com with SMTP id p127sf319154714iop.5 for ; Sun, 25 Dec 2016 23:38:49 -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:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=t4bHYEsi1T9f+RUCH1cBi01B4ZftZFUPY9ALMbyWl5w=; b=lmOsdV9zyRPUB8KmWprGU5/KD54HFaEZ8I35FsD5CA1Pwksjjb4wc4DSZBONvLtohC 7Krv6p//SeR+uLfb1YdCBmCzQdI4cOZw045SdPD68xrYk0FUxUzFOgUul04RN380Ac7v fnVeeyWshr9Goz/6SC6ORyxubEoKmAkQx4qajWmQMe7hn1W3Jelo/17r9OyAyg9nciF7 ZTB2ne0tS5RciHqBHLedYHJQ3F8otqMEsim2u7Hq1M6rih3LRGL3Orb5ZbvjgC7wtUB2 nwiZuN/JvZor/+kijUuNNpootZ/NxinORr/dSa8w8T4+SajIFnCTlaBWQTwGUfQVg0t1 Wkmg== 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:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=t4bHYEsi1T9f+RUCH1cBi01B4ZftZFUPY9ALMbyWl5w=; b=DJ5B3DSsRl8UUCgPSDyuwD9gsJs55F5UsNAfYniTB8D2Uju8z9ZqmbIxP4X2+Zcrig xTzKl3zbbWvIEI3pqoalh7d5JliglCGPY1A8lW2w7YBlKaVSxhd5mYEx7HgnIqkkBUsV D5UwePM+gLZYLbxEkO3lByptfmYnCCyR9qNAb7uZlBPyywv8R+l4ahIHIdYC/Z2XwRyK H2O1u4KrAVMtkjD4w2hyHqaLJUNLXQSUzVGBksQiB1k9HdskqG9S8lexk33h/PIXPayG tqYSBjJURCY/7nsr0UDsAy1eko6HHyDyKdSCkXmgM5t7kcEIhfbM7/+83Vn0yUSS592G SFSQ== 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=t4bHYEsi1T9f+RUCH1cBi01B4ZftZFUPY9ALMbyWl5w=; b=MCU/xaFxE08CsUDlYgkINzIfV3YEdgvupKMx4yvhtRxsxMN9+86MXZQ9inPZSBuv5w 6Xo7bHIzcV6wsMzV8v6rfXBB2tXlMZ/WdPR3sFq/+wGTPJLiN04o82JEHI/OoclDJyU+ fBXcx2+BSSH+TWdfZ0hyAuGpf3OqsP7xnXNHzqgLQGb4DfXDgDjzoQ0gNhUp1VN/FuHt manl3RMyh4X7DbIpZZ55Uj1z1rzed9HwCYVHFsjzzqrKOiuaev+/0ZmBzrxvcv9wKh4g sW8bwVhQyIUNUud+F/kLtEee6sdNNQnBxZS6jOs0ne1DOJfXV9DsSQYKCWdn04+0QZCt NPIg== X-Gm-Message-State: AIkVDXKQ8znelgzmNR5lgRmR7YNDso2vR8JMk3wPH0CX5IMCj8Mw9CM/KjED6hsA649pSA== X-Received: by 10.107.47.145 with SMTP id v17mr6672645iov.31.1482737929183; Sun, 25 Dec 2016 23:38:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.51.123 with SMTP id u56ls5033671otd.44.gmail; Sun, 25 Dec 2016 23:38:48 -0800 (PST) X-Received: by 10.157.37.151 with SMTP id q23mr1134293ota.4.1482737928341; Sun, 25 Dec 2016 23:38:48 -0800 (PST) X-Original-Sender: tongari95@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:30034 Archived-At: ------=_Part_1696_1228785115.1482737927673 Content-Type: multipart/alternative; boundary="----=_Part_1697_126514692.1482737927674" ------=_Part_1697_126514692.1482737927674 Content-Type: text/plain; charset=UTF-8 Typedef declaration is superseded by type alias declaration since C++11, its legend seems to come to the end. However, we can make typedef much more useful than it is, by allowing it to be used in accompany with variable declarations (including parameters and return types) and base-clause in a class declaration. The problem Everyone who loves templates are likely to face a problem - the name of the type being specified is too long that we don't want to spell it out twice! Although we have type alias, but unfortunately in many cases, it cannot be used at the first place and we are forced to spell the irritating names at least twice if we have to refer to the type more than once. Here are some examples: In function return type: template typename MetaFunc::type f() { using T = typename MetaFunc::type; // yuck! // Use `T` from now on... } In base-clause: template class Derived : public typename MetaFunc::type { using Base = typename MetaFunc::type; // yuck! // Use `Base` from now on... } In parameter list: template void f(SomeTemplate a, SomeTemplate b/*yuck!*/); In deduced type: auto& ref = getSomeRef(...); using T = std::remove_reference_t; // yuck! // Use `T` from now on... Evidence These discussions on the std-proposals list are also arose from the same problem: - Named base classes - decltype(return) The solution The problem comes from the inability to declare the type alias at the first place, and the solution is gonna to enable it - with the extended typedef. In function return type: template typedef typename MetaFunc::type T f() // yay! { // Use `T` from now on... } In base-clause: template class Derived : typedef public typename MetaFunc::type Base // yay! { // Use `Base` from now on... } Note how the occurrence of *access-specifier* in base-clause differ in semantic: class C : typedef T B // T: private base; B: private typedef class C : typedef public T B // T: public base; B: private typedef class C : public typedef T B // T: private base; B: public typedef class C : public typedef public T B // T: public base; B: public typedef In parameter list: template void f(typedef SomeTemplate T a, T b); // yay! In deduced type: typedef auto T& ref = getSomeRef(...); // yay! // Use `T` from now on... Note how the the type aliases declared differ: U u; typedef auto const& T1 t1 = u; // T1 -> U const& typedef auto T2 const& t2 = u; // T2 -> U Suppose we have Concept TS and its abbreviated template syntax, we can do this: void f1(typedef auto T a, T b); void f2(typedef ConceptName T a, T b); Typedef and tag declaration If the typedef contains a tag declaration, the extended usage is disabled. For example: typedef struct {...} R f(); // ill-formed void f(typedef struct {...} A a); // ill-formed typedef struct {...} S s; // ill-formed Extended typedef with mutiple indentifiers If the extended typedef has mutiple indentifiers follw the typedef-name, each identifier separated by , declares a variable. For example: typedef int* P p1 = nullptr, p2 = nullptr, *p3 = nullptr; // p1 & p2 are both `int*`, and p3 is `int**` That's the rough idea I have, I haven't think about the technical aspect of this approach. Feedbacks are welcome! -- 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/cfbe556f-214a-4245-b257-f746424c63f2%40isocpp.org. ------=_Part_1697_126514692.1482737927674 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Typedef declaration is superseded by type alias decla= ration since C++11, its legend seems to come to the end. However, we can ma= ke typedef=C2=A0much more usef= ul than it is, by allowing it to be used in accompany with variable declara= tions (including parameters and return types) and base-clause in a class de= claration.

The problem=

Everyone who loves templates are likely to face a= problem - the name of the type being specified is too long that we don'= ;t want to spell it out twice!
Although we have type alias, but u= nfortunately in many cases, it cannot be used at the first place and we are= forced to spell the irritating names at least twice if we have to refer to= the type more than once.
Here are some examples:

<= /div>
In function return type:
template<blahblah...>
typename MetaFunc<blah= blah...>= ;::type f<= /span>()
{
=C2=A0 =C2=A0 using T =3D typename MetaFunc<blahblah= ....>::t= ype; // yuck!
=C2=A0 =C2=A0 // Use `T` from now= on...
= }

In base-clause:
template<blahblah...>
class Derived : public<= span style=3D"color: #000;" class=3D"styled-by-prettify"> typename MetaFunc<blahblah...>::type
{
=C2=A0 =C2=A0 using Base =3D typename MetaFunc<blahblah...>::type; // yuck!
=C2=A0 =C2=A0 // Use `Base` from now on...
}

In= parameter list:
template<blahblah= ....>void f(SomeTemplate<blahblah...> a, SomeTemplate<blahblah...> b/*yuck!= */);

In deduced type:
auto& ref =3D getSomeRef(...);
u= sing T =3D std::remove_reference_t<decltype(ref)>; // yuck!
// Use `T` from now on...

= Evidence

These discussions on the std-proposals list are also arose from the = same problem:
<= div>
The solution

The problem comes from the inability to declare the type alias at the= first place, and the solution is gonna to enable it - with the extended typedef.

In function return type:
template<blahblah...>
typedef <= /span>typename MetaFunc<blahblah...>::type T f() // yay!
{
=C2=A0 =C2=A0 // Use `T` from now on...
}

In base-clause:
template<blahblah= ....>class Derived : typedef public t= ypename MetaFunc<blahblah...>::type Base // yay!
{
=C2=A0 =C2=A0 // Use `Base` from now on...
}

Note how the occurrence of access-specifier=C2=A0in base-cla= use differ in semantic:
class C : typedef T B // T: private base; B= : private typedef
class C <= /span>: typedef public T B // T: public base; B: private typedef
class C : public typedef T B // T= : private base; B: public typedef
class C : public typedef public T B // T: public base; B: public typedef

In parameter list:
template<blahblah...>
void f(typedef SomeT= emplate<= ;blahblah<= /span>...> T a, T b); // yay!

In deduced type:
<= div class=3D"subprettyprint">typedef = auto T& ref =3D getSomeRef(...); // yay!
// Use `T` from now on...

N= ote how the the type aliases declared differ:
U u;
typedef auto= const& T1 t1 =3D u; // T1 -> U const&
typedef auto T2 const= & t2 <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> u; // T2 -> U
=
Suppose we have Concept TS and its abbreviated template synt= ax, we can do this:
=
void f1= (typedef auto T a, T b);
void f2= (typedef ConceptName T a, T b);


Typedef and tag declaration

If the typede= f=C2=A0contains a tag declaration, the extended usage is disabled. F= or example:
typedef struct<= /span> {...} R f(); // ill-formed
void f(typedef = struct {...} A a); // ill-formed
typedef struct {...= } S s; // ill-formed
=


Extended typedef = with mutiple indentifiers

If the extended t= ypedef has mutiple indentifiers follw the typedef-name, each identifier sep= arated by ,=C2=A0declares a variable. F= or example:
typedef in= t*<= span style=3D"color: #000;" class=3D"styled-by-prettify"> P p1 =3D nullptr, p2 =3D nullptr, = *p3 =3D nullptr; // p1 & p2 are both `int*`, and p3 is `int**`
=


That's the rough idea I = have, I haven't think about the technical aspect of this approach.
Feedbacks are welcome!

--
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/cfbe556f-214a-4245-b257-f746424c63f2= %40isocpp.org.
------=_Part_1697_126514692.1482737927674-- ------=_Part_1696_1228785115.1482737927673-- .