220 30772 article Path: news.gmane.org!.POSTED!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Make Typedef Great Again Date: Sun, 5 Feb 2017 02:03:45 -0800 (PST) Lines: 506 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_893_1943674408.1486289025814" X-Trace: blaine.gmane.org 1486289027 17468 195.159.176.226 (5 Feb 2017 10:03:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 5 Feb 2017 10:03:47 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCRIRSPDTQIRBAXR3PCAKGQETXC7KQI@isocpp.org Sun Feb 05 11:03:43 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f72.google.com ([209.85.214.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1caJfa-0004Iy-Fz for gclcip-std-proposals@m.gmane.org; Sun, 05 Feb 2017 11:03:42 +0100 Original-Received: by mail-it0-f72.google.com with SMTP id s10sf56391278itb.7 for ; Sun, 05 Feb 2017 02:03:48 -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: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=D+LN1ZeeRhFS6aB4SLhX6y3fU8zpiCpC/BW+dkdE+4Y=; b=pcQG9+d5oV0CXWnrKaMXMxgLYiTDUlkSgpHaL3e2bCJFZYW6un4+lOZTpItq6qDbnE hddHJsdon20y2654HD9WF8r9fOb4zYsQP3maanjrs12fajL78fnb43FumLd6/AZ/KroH fG/8wyXFZBaOtErP23gywVIoZqiy2+NysFIUuvY9zbOkBNgJxKpq0AMu4cG3EVkxQe8V fLHaxlj0M0fUrXYe19JHQOO1kKcy2GPS2OnNptEV+OxgvMm87VZuxvPOvs6XilvaDSDK R3SVm6gAHkiPp1tyMx076MJsyj5k3ybE8R8S/suGYS213RRijwJc7kKnuIEBJoymbhwD AKNA== 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: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=D+LN1ZeeRhFS6aB4SLhX6y3fU8zpiCpC/BW+dkdE+4Y=; b=W0N9fyGG99sukLLuAfQEV9ZAVXM2HpKrAtmLCFSWk5M3aqLL3qBdC0Im2wCfDoyzvJ wn03oM5kD4ycfmGi3QNBUOKQPcgMj6NNY8En8Et5AW0EcnhabtOJtfooDWcrJ4uiJivI EBqYFvROaKiUor0GUPREJVtMaGkx3eXkD237A47s7714qE4OoBpFv12J4LNMXpEAOCM7 LqopiVgOfuLmODtsnKooeC1rwaa/HpeZkpUrLKtRQJXXJPIZDAMdjMAl4CdFo5fGlDIU L8madfrlvlbyV/t8oBuxUJUhyC5cZCXfh56dbgI338VM4m40T0qcerRSMLIlmObWjbFA KPxA== X-Gm-Message-State: AMke39n7luotY39mGaiJhjle2G7XGkdLOFHxy6nJvLpIayobhqHWkYTmRlYGs820uxkGyQ== X-Received: by 10.107.150.18 with SMTP id y18mr1006632iod.78.1486289027765; Sun, 05 Feb 2017 02:03:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.42.46 with SMTP id t43ls11958913ota.17.gmail; Sun, 05 Feb 2017 02:03:46 -0800 (PST) X-Received: by 10.157.41.149 with SMTP id n21mr300124otb.4.1486289026588; Sun, 05 Feb 2017 02:03:46 -0800 (PST) In-Reply-To: X-Original-Sender: bengt.gustafsson@beamways.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:30772 Archived-At: ------=_Part_893_1943674408.1486289025814 Content-Type: multipart/alternative; boundary="----=_Part_894_1115334187.1486289025816" ------=_Part_894_1115334187.1486289025816 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like it, but it does take some getting used to the stacking of=20 identifiers in parameter and variable declaration cases. Also, in these=20 cases, I suspect there could be some parsing issues, especially if the name= =20 of the type is defined in an outer scope. Maybe you'd have to clarify why this is not a problem. Then again, I can't really produce a=20 problematic example so maybe I'm just seeing ghosts here. However, an=20 example involving an array size bracket would be interesting as it comes=20 after the identifier. This brings up a wrinkle in the last example: typedef int* P p1 =3D nullptr, p2 =3D nullptr, *p3 =3D nullptr; // p1 & p2 = are=20 both `int*`, and p3 is `int**` Here you must make it clear that there is a new rule in play compared to=20 what would be the most logical interpretation compared to current language= =20 rules: That the * would only apply to the next identifier being declared.= =20 Instead the new rule is as you explain, which is necessary for the use case= =20 of return type. Den m=C3=A5ndag 26 december 2016 kl. 08:38:48 UTC+1 skrev TONGARI J: > > Typedef declaration is superseded by type alias declaration since C++11,= =20 > its legend seems to come to the end. However, we can make typedef much=20 > more useful than it is, by allowing it to be used in accompany with=20 > variable declarations (including parameters and return types) and=20 > base-clause in a class declaration. > > The problem > > Everyone who loves templates are likely to face a problem - the name of= =20 > the type being specified is too long that we don't want to spell it out= =20 > twice! > Although we have type alias, but unfortunately in many cases, it cannot b= e=20 > used at the first place and we are forced to spell the irritating names a= t=20 > 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 =3D typename MetaFunc::type; // yuck! > // Use `T` from now on... > } > > In base-clause: > template > class Derived : public typename MetaFunc::type > { > using Base =3D 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 =3D getSomeRef(...); > using T =3D std::remove_reference_t; // yuck! > // Use `T` from now on... > > Evidence > > These discussions on the std-proposals list are also arose from the same= =20 > problem: > > - Named base classes=20 > > - decltype(return)=20 > > =20 > > The solution > > The problem comes from the inability to declare the type alias at the=20 > first place, and the solution is gonna to enable it - with the extended= =20 > 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 = //=20 > yay! > { > // Use `Base` from now on... > } > > Note how the occurrence of *access-specifier* in base-clause differ in=20 > 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 =3D getSomeRef(...); // yay! > // Use `T` from now on... > > Note how the the type aliases declared differ: > U u; > typedef auto const& T1 t1 =3D u; // T1 -> U const& > typedef auto T2 const& t2 =3D u; // T2 -> U > > Suppose we have Concept TS and its abbreviated template syntax, we can do= =20 > 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=20 > 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,= =20 > each identifier separated by , declares a variable. For example: > typedef int* P p1 =3D nullptr, p2 =3D nullptr, *p3 =3D nullptr; // p1 & p= 2 are=20 > both `int*`, and p3 is `int**` > > > That's the rough idea I have, I haven't think about the technical aspect= =20 > of this approach. > Feedbacks are welcome! > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/cd4db888-d877-4249-91f6-cfacda0a2afe%40isocpp.or= g. ------=_Part_894_1115334187.1486289025816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like it, but it does take some getting used to the stack= ing of identifiers in parameter and variable declaration cases. Also, in th= ese cases, I suspect there could be some parsing issues, especially if the = name of the type is defined in an outer scope. Maybe you'd have to
= clarify why this is not a problem. Then again, I can't really produce a= problematic example so maybe I'm just seeing ghosts here. However, an = example involving an array size bracket would be interesting as it comes af= ter the identifier. This brings up a wrinkle in the last example:

typedef=C2=A0int*=C2=A0P p1=C2=A0=3Dnullptr,=C2=A0p2=C2=A0=3D=C2=A0nullptr,=C2=A0*p3=C2=A0=3D=C2=A0nullpt= r;=C2=A0// p= 1 & p2 are both `int*`, and p3 is `int**`

= Here you must make it clear that= there is a new rule in play compared to what would be the most logical int= erpretation compared to current language rules: That the * would only apply= to the next identifier being declared. Instead the new rule is as you expl= ain, which is necessary for the use case of return type.
<= br>
Den m=C3=A5ndag 26 december 2016 kl. 08:38:48 UTC+1 skrev TONGARI J:=
Typedef = declaration is superseded by type alias declaration since C++11, its legend= seems to come to the end. However, we can make typedef=C2=A0much more useful than it is, by allowing it = to be used in accompany with variable declarations (including parameters an= d return types) and base-clause in a class declaration.

<= /div>
The problem

Ever= yone who loves templates are likely to face a problem - the name of the typ= e 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 irritatin= g names at least twice if we have to refer to the type more than once.
Here are some examples:

In function return t= ype:
template<blahblah...>
typename MetaFunc<blahblah...>::= type f()
{<= span style=3D"color:#000">
=C2=A0 =C2=A0 using T =3D typename MetaFunc<blahblah...>::type; // yuck!
=C2=A0 =C2=A0 // Us= e `T` from now on...
}

In base-cla= use:
template<blahblah...>
class Derived : public typename MetaFunc<blahblah...>::type
{
=C2=A0 =C2=A0 using = Base = =3D typ= ename M= etaFunc<blahblah...>::type; // yuck!
=C2=A0 =C2=A0 // Us= e `Base` from now on...
}

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

In deduced type:
auto= & <= span style=3D"color:#008">ref =3D getSomeRef(...);
<= /span>using T = =3D std= ::remov= e_reference_t<decltype(ref)>; // yuck!
// Use `T` from = now on...

Evi= dence

These discuss= ions on the std-proposals list are also arose from the same problem:
<= div>

The solution

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

In function re= turn type:
template<blahblah...>
typedef 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 typename <= span style=3D"color:#606">MetaFunc<blahblah..= ..>::type Base // yay!
{
=C2=A0 =C2=A0 // Use `Base` from now on...
}

Note how the occurrence of access-specifier=C2=A0in = 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 bas= e; B: public typedef
class C : public typedef public T B // T: public base; B: public typedef

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

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

Note how the the type aliases declared differ:
U u;
typedef auto const& T1 t1 =3D u; // T1 -> U const&<= br>typedef auto T2 const& t2 =3D u; //= T2 -> U

Suppose we have Co= ncept 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=C2= =A0contains a tag declaration, the extended usage is disabled. For example:=
typedef struct {...} R f<= /span>(); // ill-formed
void f(t= ypedef = struct = {...} A a); //= ill-formed
typedef struct {...} S s; // ill-formed


=
Extended typedef with mutiple indentifiers

If the extended typedef has mutiple indentifiers foll= w the typedef-name, each identifier separated by ,= =C2=A0declares a variable. For example:
typedef int* P p1 =3D nullptr, p2 =3D nullptr, *p3= =3D nullptr;<= /span> // p1 &= amp; p2 are both `int*`, and p3 is `int**`
<= div>

That's the rough idea I have, I haven= 't think about the technical aspect of this approach.
Feedbac= ks 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/cd4db888-d877-4249-91f6-cfacda0a2afe= %40isocpp.org.
------=_Part_894_1115334187.1486289025816-- ------=_Part_893_1943674408.1486289025814-- .