220 5617 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Possibilities for uniform type name declaration Date: Tue, 30 Jul 2013 19:02:15 +0300 Lines: 154 Approved: news@gmane.org Message-ID: References: <83a1ebce-b43d-4d3f-86ea-83b1f85fd432@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd766de98e02d04e2bcbb42 X-Trace: ger.gmane.org 1375200135 8770 80.91.229.3 (30 Jul 2013 16:02:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Jul 2013 16:02:15 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBCGH36HQKGQEPGFZIOQ@isocpp.org Tue Jul 30 18:02:18 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f199.google.com ([209.85.216.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V4CNN-0006vL-KY for gclcip-std-proposals@m.gmane.org; Tue, 30 Jul 2013 18:02:17 +0200 Original-Received: by mail-qc0-f199.google.com with SMTP id j10sf2411559qcx.10 for ; Tue, 30 Jul 2013 09:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:date:message-id :subject:from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=XZPX4mrnHnRGn6LGnVV2AeWMwGv+n4KYGed9f1whu0k=; b=pqvF7TuzcACWhrmZfT6fseo/HO5fNBljrcPCqLOU2OmgxlDxLDF2I7EJv5oWDg8eOD Oexhr3kW7iz+RsWAaG89clIELeAeLM2xMD2Q7CYdh7yPXWHOK+4Qixw0u772DK4Z946q EKBZ3vRIi251ty9ahnRzjXXevLxz0G9hsBg0oDW2OvrOZZsGM+xobgTr93Upiv4P7DPe Nta5OxiCVEBhHZ0YsQ3nnJuyajN+fDHvO+fsLCDiBn2d/WdHrKAP1XyvRoU/1Iod51l/ XuQCNcA4RQCx3UZnsfhFwKoPJJt8giJfzOJZ8jlXiS7TUGY7Ie0O7W7+4g3p4l526dV9 dCFg== X-Received: by 10.236.120.232 with SMTP id p68mr33063932yhh.43.1375200136737; Tue, 30 Jul 2013 09:02:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.132.197 with SMTP id ow5ls271164qeb.97.gmail; Tue, 30 Jul 2013 09:02:16 -0700 (PDT) X-Received: by 10.49.35.108 with SMTP id g12mr79284452qej.86.1375200136092; Tue, 30 Jul 2013 09:02:16 -0700 (PDT) Original-Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [2607:f8b0:400d:c02::232]) by mx.google.com with ESMTPS id g8si9532571qam.169.2013.07.30.09.02.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 09:02:16 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::232 as permitted sender) client-ip=2607:f8b0:400d:c02::232; Original-Received: by mail-qe0-f50.google.com with SMTP id q19so2264195qeb.23 for ; Tue, 30 Jul 2013 09:02:16 -0700 (PDT) X-Received: by 10.49.53.10 with SMTP id x10mr10804798qeo.46.1375200135928; Tue, 30 Jul 2013 09:02:15 -0700 (PDT) Original-Received: by 10.224.181.138 with HTTP; Tue, 30 Jul 2013 09:02:15 -0700 (PDT) In-Reply-To: <83a1ebce-b43d-4d3f-86ea-83b1f85fd432@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::232 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@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:5617 Archived-At: --047d7bd766de98e02d04e2bcbb42 Content-Type: text/plain; charset=ISO-8859-1 On 30 July 2013 18:55, Michael Price - Dev wrote: > I'm thinking of writing a proposal to expand the valid uses of the > 'typename' keyword. The basic idea is fairly simple. Within any > particular lexical scope, if the programmer wishes to instruct the compiler > that a particular identifier should be considered a type, it may be > prefaced with the typename keyword. Thus: > > typename X; // forward declare a type 'X'; > typename X::value; // forward declare a type 'value' that is nested within > type 'X' (accessibility problems... more on that later) > > template > void func () > { > typename T::value; // 'T::value' will always be a type within this > scope > } > > This would help solve several problems: > > > 1. Using 'class' or 'struct' in forward declarations. Both work, but > it is awfully confusing. 'typename' would become the "appropriate" way to > do this. > > Do you expect typename to cover non-class types, too, since it already does that for its traditional uses? > > 1. > 2. Removes the requirement for a full class declaration for nested > types. There could still be accessibility problems, but I think we could > still issue diagnostics for these at a later point (when we have the full > class declaration). An implementation of that would probably go a long > ways I would assume. > > This is oft-requested, so I'm certainly interested in it. > > 1. > 2. In templates, we wouldn't have to resort to using type aliases to > avoid putting typename in front of an identifier every time we used it. (I > thought this already worked, but ideone.com disagreed). > > Would you like to elaborate? I can do eg. template void f() { using type = typename T::type; type x; type y; } struct X { typedef int type; }; int main() { f(); } -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7bd766de98e02d04e2bcbb42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 30 July 2013 18:55, Michael Price - Dev <michael.b.= price.dev@gmail.com> wrote:
I'm thinking of writi= ng a proposal to expand the valid uses of the 'typename' keyword. = =A0The basic idea is fairly simple. =A0Within any particular lexical scope,= if the programmer wishes to instruct the compiler that a particular identi= fier should be considered a type, it may be prefaced with the typename keyw= ord. Thus:

typename X; // forward= declare a type 'X';
typename X::value; // forward declare a type 'value' that = is nested within type 'X' (accessibility problems... more on that l= ater)

template <typename T>
void func ()
{
=A0 =A0 typename T::value; // &#= 39;T::value' will always be a type within this scope
<= font face=3D"courier new, monospace">}

This= would help solve several problems:

  1. Using 'class' or 'struct' in fo= rward declarations. =A0Both work, but it is awfully confusing. =A0'type= name' would become the "appropriate" way to do this.

Do you expect typename to cover= non-class types, too, since it already does that for its traditional uses?=
=A0
  2. Removes the requirement for a full class declaration = for nested types. =A0There could still be accessibility problems, but I thi= nk we could still issue diagnostics for these at a later point (when we hav= e the full class declaration). =A0An implementation of that would probably = go a long ways I would assume.
This is oft-requested, so I'm certain= ly interested in it.
=A0
  2. In templates, we wouldn't have to resort to using= type aliases to avoid putting typename in front of an identifier every tim= e we used it. (I thought this already worked, but ideone.com disagreed).

Would you like to elaborat= e? I can do eg.

template <class T> void f()
{
=A0=A0 us= ing type =3D typename T::type;
=A0=A0 type x;
=A0=A0 type y;
} <= br>
struct X
{
=A0=A0 typedef int type;
};

int main()
{
=A0=A0 f<= ;X>();
}

--
 
---
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
 
 
--047d7bd766de98e02d04e2bcbb42-- .