220 14200 <14ff5bcb-5efb-46da-9b86-54382363c3b0@isocpp.org> article Path: news.gmane.org!not-for-mail From: contact@ncomputers.org Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Templetized namespaces Date: Fri, 24 Oct 2014 08:59:20 -0700 (PDT) Lines: 369 Approved: news@gmane.org Message-ID: <14ff5bcb-5efb-46da-9b86-54382363c3b0@isocpp.org> References: <4cfc2db6-97da-4750-9296-5aaaa3475014@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_217_1200739447.1414166360021" X-Trace: ger.gmane.org 1414166369 20864 80.91.229.3 (24 Oct 2014 15:59:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2014 15:59:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC4MBZFHTYJRBWHOVGRAKGQEZPFGNMQ@isocpp.org Fri Oct 24 17:59:24 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XhhGs-0005fb-DK for gclcip-std-proposals@m.gmane.org; Fri, 24 Oct 2014 17:59:22 +0200 Original-Received: by mail-oi0-f71.google.com with SMTP id v63sf5101248oia.6 for ; Fri, 24 Oct 2014 08:59:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=hM+IXAwFPc5wqyQSuClFsn9fuN6BdinBVUVjjVq/Ph4=; b=efAL2mA3ockS2ASX2OTdytg2maEyBPPoxnmW3pseMTrHO3VmRGN+X5wGPPNz5etMh7 tIKH9ohLU8GxLGH/gczXWQDaEYS0m+MEjX26Q/ryas1RGZK6P1sQWlDvREzPkK/xIlxd i7IOVmcT0QerE658x5lTFkvSmZjgFtKG/5BqZlGlVyCzg+04t/K8mV+G8kPiDEYABNUn LwZ6Hv+jInxGgs5pZuCeIazkDmVGN5c6/laEyala4dIs7IqE7CpjN22FkE2OjA+1YN92 +NstYdEdmNbdWSRve5Z7cOrYSBXyaOXDchrqlwfXdmepI5AtXbOpoZCX0AppN0eURaxs uoKg== X-Gm-Message-State: ALoCoQkD3ulrz6rxOCwG1QbWyGSDm/n4ThhLwv/nHuuWhB5LETPy0FVVnYnISz8cyGJKbk6JI3Ab X-Received: by 10.182.247.101 with SMTP id yd5mr7850075obc.41.1414166361501; Fri, 24 Oct 2014 08:59:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.40.136 with SMTP id x8ls613097obk.54.gmail; Fri, 24 Oct 2014 08:59:20 -0700 (PDT) X-Received: by 10.182.138.101 with SMTP id qp5mr648obb.42.1414166360558; Fri, 24 Oct 2014 08:59:20 -0700 (PDT) In-Reply-To: X-Original-Sender: contact@ncomputers.org 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:14200 Archived-At: ------=_Part_217_1200739447.1414166360021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that templetized templates should be allowed using nested=20 namespaces by classes, for example: template class A{ namespace B{ Typename Variable; } }; PF, ncomputers Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb Klaim - Jo=C3=ABl Lamot= te: > > Sorry I didn't see your reply before. > > On Sun, Jan 26, 2014 at 1:52 AM, dgutson . > wrote: > >> On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte > > wrote: >> >>> I had the exact same ideas few months ago after finding myself doing=20 >>> generic library which all types would depend on the same type, >>> and remarking how much duplication could be avoided if I was allowed to= =20 >>> specify that a whole bunch of types would automatically have an additio= nal=20 >>> template parameter implicitly. >>> >>> namespace blah< typename X > >>> { >>> class K {}; >>> template < class T > class U {}; >>> } >>> >>> would be translated to=20 >>> >>> namespace blah >>> { >>> template< typename X > >>> class K {}; >>> template< typename X, class T > class U {}; >>> } >>> >>> >>> However, after weeks of thinking about this I concluded that: >>> >>> 1. namespace are not the appropriate construct for this, they really= =20 >>> are too different and not really encapsulating anything than names; >>> 2. there are a lot of potential issues related to the order of templat= e=20 >>> arguments; >>> >> >> Please elaborate about the last two points. >> =20 >> > > Basically, namespaces don't have a unique definition and are only=20 > affecting naming. > Therefore, what would be better to template would be something like a=20 > module or a class or a mixin (a class component). > > =20 > >> 3. there is a potential issue for reading the code as you need to see= =20 >>> the namespace declaration before being able to follow the rest of the c= ode. >>> >> >> I don't find this issue different than any other template declaration,= =20 >> for example a nested class of a template class. >> =20 >> > > Yes, it's a weak point but apparently some people have trouble with this. > Not sure if it should be taken into account. > =20 > >> What I mean here is basically the same argument that makes Clang=20 >>> developers avoid anonymous namespaces. >>> >>> Also, I believe that the real thing I do want when I'm writing these=20 >>> generic libraries is actually to generate a whole bunch of types, using= =20 >>> another type as argument of the process to generate the wanted types. >>> >> >> We agree on that. >> =20 >> >>> Basically, I want one of the features that the Reflection group is=20 >>> supposed to look for. >>> >> >> I'm working on statement-templates.googlecode.com but that's something I= =20 >> will post in this list later. >> =20 >> >>> >>> Since that realization, I think that efforts should be put to have a ne= w=20 >>> reflection construct instead of making namespace do something too diffe= rent=20 >>> from it's initial use. >>> >>> >>> >>> --=20 >>> =20 >>> ---=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to std-proposal...@isocpp.org . >>> To post to this group, send email to std-pr...@isocpp.org = .. >>> Visit this group at=20 >>> http://groups.google.com/a/isocpp.org/group/std-proposals/. >>> >> >> >> >> --=20 >> Who=E2=80=99s got the sweetest disposition? >> One guess, that=E2=80=99s who? >> Who=E2=80=99d never, ever start an argument? >> Who never shows a bit of temperament? >> Who's never wrong but always right? >> Who'd never dream of starting a fight? >> Who get stuck with all the bad luck?=20 >> >> --=20 >> =20 >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at=20 >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_217_1200739447.1414166360021 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that templetized templates should be allowed using= nested namespaces by classes, for example:

template<typename Typename>
class A{
   = ; namespac= e B= {
      &= nbsp; Type= name Variable= ;
    <= span style=3D"color: #660;" class=3D"styled-by-prettify">}
};

PF, nco= mputers

Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb Klaim - = Jo=C3=ABl Lamotte:
Sorry I didn't see your reply before.

On Sun, Jan 26, 2014 at 1:52 AM, dgutson . <daniel...@gmail.com> wrote:=
On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <= span dir=3D"ltr"><mjk...@gmail.com<= /a>> wrote:
I had the exact same ideas few month= s ago after finding myself doing generic library which all types would depe= nd on the same type,
and remarking how much duplication could be avoided if I was allowed t= o specify that a whole bunch of types would automatically have an additiona= l template parameter implicitly.

namespace blah< typename X >
{
     class K {};
     template &l= t; class T > class U {};
}

would be translated to 

=
namespace blah
{
    template< typename X >
  &nb= sp; class K {};
    template< typename X, class T &g= t; class U {};
}


However, after weeks of thinking = about this I concluded that:

 1. namespace are not the appropriate construct for this, they really = are too different and not really encapsulating anything than names;
 2. there are a lot of potential issues related to the order of tem= plate arguments;

 



= Yes, it's a weak point but apparently some people have trouble with this.
Not sure if it should be taken into account.
 
     What= I mean here is basically the same argument that makes Clang developers avo= id anonymous namespaces.

Also, I believe that the real thing I do want when I'm = writing these generic libraries is actually to generate a whole bunch of ty= pes, using another type as argument of the process to generate the wanted t= ypes.

We agree on that.
=
 
Basically, I want one of the features that the Reflection group is sup= posed to look for.

I'm w= orking on statement-templates.googlecode.com but= that's something I will post in this list later.
 

Since that realization, I think that efforts should be put to have a n= ew reflection construct instead of making namespace do something too differ= ent from it's initial use.



--
 
---
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-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.



=
--
Who=E2=80=99s got the sweetest disposition?
One guess, that= =E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who neve= r shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad lu= ck?=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-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_217_1200739447.1414166360021-- .