220 8812 article Path: news.gmane.org!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Templetized namespaces Date: Sat, 25 Jan 2014 22:52:05 -0200 Lines: 231 Approved: news@gmane.org Message-ID: 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=bcaec52beba504dba004f0d5006d X-Trace: ger.gmane.org 1390697520 17369 80.91.229.3 (26 Jan 2014 00:52:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 00:52:00 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDE3NBMV6UFBBOFYSGLQKGQE2H3MKXY@isocpp.org Sun Jan 26 01:52:08 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f71.google.com ([209.85.161.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W7DxI-0005Fy-Rj for gclcip-std-proposals@m.gmane.org; Sun, 26 Jan 2014 01:52:08 +0100 Original-Received: by mail-fa0-f71.google.com with SMTP id v1sf8486922fav.10 for ; Sat, 25 Jan 2014 16:52:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state: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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=oj0d8lDMIlav0MbFbI36keZ/tx6UPOc79QT+s+vipgY=; b=Ue3hdWZublEHf+YNlvE3vW0o+oReWRtvbXLW6xJ1OwbCWhgo+xb28CEqSSg/r++lFB fizNxwR1AYcQ6i5XGRnAANVHWl8mgJs2thrEmuPmD04LRTJWQ+JoWnHB7t5c8M5IzLey g5TGoX4NLcLwhvKYdbWUHt9VNaOZyBRQ06R8GDOvfJazAKRMqBZ2tYdacktATGwaoQxY 0jArC1VZtNrzROAfC0VvFl1MpUUZioAE92RjImjFlbJpJp87km2YMFwKrDOeMRTaHqYe CAyHx2qI8Fqv2BFnVBeA3EGVlUmiJh/aVNaLFLUgec1F+Zyuc5zceLzfueZoCCrXCz2q i58g== X-Gm-Message-State: ALoCoQn3YC+Gvzxsq4L/m1fQpfwiKCgLMjsk124cjgIyJxm+nCkt9kcqbi19bzt0nKhJlix7ySm0 X-Received: by 10.112.87.100 with SMTP id w4mr3983944lbz.24.1390697528389; Sat, 25 Jan 2014 16:52:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.93.226 with SMTP id cx2ls663208wib.27.canary; Sat, 25 Jan 2014 16:52:07 -0800 (PST) X-Received: by 10.204.53.75 with SMTP id l11mr14527281bkg.35.1390697527725; Sat, 25 Jan 2014 16:52:07 -0800 (PST) Original-Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [2607:f8b0:400e:c02::22e]) by mx.google.com with ESMTPS id pj2si8614294bkb.19.2014.01.25.16.52.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Jan 2014 16:52:07 -0800 (PST) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c02::22e as permitted sender) client-ip=2607:f8b0:400e:c02::22e; Original-Received: by mail-pd0-f174.google.com with SMTP id z10so4472869pdj.33 for ; Sat, 25 Jan 2014 16:52:05 -0800 (PST) X-Received: by 10.66.27.107 with SMTP id s11mr22562244pag.64.1390697525859; Sat, 25 Jan 2014 16:52:05 -0800 (PST) Original-Received: by 10.70.78.200 with HTTP; Sat, 25 Jan 2014 16:52:05 -0800 (PST) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c02::22e as permitted sender) smtp.mail=danielgutson@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:8812 Archived-At: --bcaec52beba504dba004f0d5006d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=EBl Lamotte = wrote: > I had the exact same ideas few months ago after finding myself doing > generic library which all types would depend on the same type, > and remarking how much duplication could be avoided if I was allowed to > specify that a whole bunch of types would automatically have an additiona= l > template parameter implicitly. > > namespace blah< typename X > > { > class K {}; > template < class T > class U {}; > } > > would be translated to > > 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 are > too different and not really encapsulating anything than names; > 2. there are a lot of potential issues related to the order of template > arguments; > Please elaborate about the last two points. > 3. there is a potential issue for reading the code as you need to see th= e > namespace declaration before being able to follow the rest of the code. > I don't find this issue different than any other template declaration, for example a nested class of a template class. > What I mean here is basically the same argument that makes Clang > developers avoid 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 types, using > another type as argument of the process to generate the wanted types. > We agree on that. > Basically, I want one of the features that the Reflection group is > supposed to look for. > I'm working 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 new > reflection construct instead of making namespace do something too differe= nt > 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 > 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/. > --=20 Who's got the sweetest disposition? One guess, that's who? Who'd 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 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/. --bcaec52beba504dba004f0d5006d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=EBl Lamotte <mjklaim= @gmail.com> wrote:
I had the exac= t same ideas few months ago after finding myself doing generic library whic= h all types would depend on the same type,
and remarking how much duplication could be avoi= ded if I was allowed to specify that a whole bunch of types would automatic= ally have an additional template parameter implicitly.

namespace b= lah< typename X >
{
     class K {};
     template < class T > class U {};
}

would be translated to 

namespace blah
{
    template< typename X >= ;
    class K {};
    template< typename X, class T > class = U {};
}


=
However, after weeks of thinking about thi= s 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 relat= ed to the order of template arguments;

Please elaborate about the last two = points.
 
 3. there is a potential issue for reading = the code as you need to see the namespace declaration before being able to = follow the rest of the code.

I = don't find this issue different than any other template declaration, fo= r example a nested class of a template class.
 
     What I mean here is basically the same argument that= makes Clang developers avoid anonymous namespaces.

Also, I bel= ieve that the real thing I do want when I'm writing these generic libra= ries is actually to generate a whole bunch of types, using another type as = argument of the process to generate the wanted types.

We agree on that.
 
Basically, I want one of the features that the R= eflection group is supposed to look for.

<= /div>
I'm working on statement-templates.googlecode.com but that's somethin= g I will post in this list later.
 

Since that realization, I think that efforts sho= uld be put to have a new reflection construct instead of making namespace d= o something too different from it's initial use.


<= div class=3D"gmail_extra">

--
 
---
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/gro= up/std-proposals/.



--
= Who’s got the sweetest disposition?
One guess, that’s who?Who’d never, ever start an argument?
Who never shows a bit of te= mperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the ba= d luck?=20

--
 
---
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>.
--bcaec52beba504dba004f0d5006d-- .