220 8752 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Templetized namespaces Date: Wed, 22 Jan 2014 13:47:34 +0100 Lines: 117 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=001a11c1bce86c594004f08e87fe X-Trace: ger.gmane.org 1390394850 18512 80.91.229.3 (22 Jan 2014 12:47:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 12:47:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD3NR2WQQ4IBBZ7372LAKGQEFT36GVA@isocpp.org Wed Jan 22 13:47:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W5xDU-0005el-Ts for gclcip-std-proposals@m.gmane.org; Wed, 22 Jan 2014 13:47:37 +0100 Original-Received: by mail-ie0-f198.google.com with SMTP id ar20sf23462510iec.9 for ; Wed, 22 Jan 2014 04:47:36 -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=s0pfTQpVV4mB8+eBpGBfn17ssbSZXICn94TDmPbKpTc=; b=cMvAwbtVuLqEnQ7dxioSoCbloPP2H5P+Eszm+S5w8Gg6EXXLACbIsxFKsq48zDyunT 1BQ38toQrkLG9bPnqkxfbcaG0xjZa/nnoK2UHWyO1mtM02OvujSmhXszcnwlpVPtb3aw VITu+E8Lb72efaXiT+vLWDmvS6QqAgptDn6yg+uhk8QcTExLAieuaGGIO0p7V8lW3dUT BFawDNwMJ0/jALs3ptYmRmxhMb1SANlqkhuPjSUenyg2RE/rat+wXob7pyeppN6LlNYr zdkh1JggGkc7BbmgXlV63ccGunoqbpGMb6pAgmn5r62FX9B4dTtqHUI1MniNNwEHD4Pf omlA== X-Gm-Message-State: ALoCoQk2Oj73SfTRr0i6O0xjyuZEjNadlhNerJt953AT8iC42cSDO+y1iafWYHSAKnViq+nB10HL X-Received: by 10.182.121.39 with SMTP id lh7mr471441obb.46.1390394855988; Wed, 22 Jan 2014 04:47:35 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.82.49 with SMTP id f17ls74255qey.54.gmail; Wed, 22 Jan 2014 04:47:35 -0800 (PST) X-Received: by 10.236.21.244 with SMTP id r80mr1215410yhr.103.1390394855276; Wed, 22 Jan 2014 04:47:35 -0800 (PST) Original-Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [2607:f8b0:4003:c02::231]) by mx.google.com with ESMTPS id 21si8421118yhx.206.2014.01.22.04.47.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 04:47:35 -0800 (PST) Received-SPF: pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c02::231 as permitted sender) client-ip=2607:f8b0:4003:c02::231; Original-Received: by mail-oa0-f49.google.com with SMTP id i7so352202oag.8 for ; Wed, 22 Jan 2014 04:47:35 -0800 (PST) X-Received: by 10.60.50.105 with SMTP id b9mr1143140oeo.34.1390394854887; Wed, 22 Jan 2014 04:47:34 -0800 (PST) Original-Received: by 10.76.20.209 with HTTP; Wed, 22 Jan 2014 04:47:34 -0800 (PST) In-Reply-To: X-Original-Sender: mjklaim@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of mjklaim@gmail.com designates 2607:f8b0:4003:c02::231 as permitted sender) smtp.mail=mjklaim@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:8752 Archived-At: --001a11c1bce86c594004f08e87fe Content-Type: text/plain; charset=UTF-8 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 additional 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; 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. 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. Basically, I want one of the features that the Reflection group is supposed to look for. Since that realization, I think that efforts should be put to have a new reflection construct instead of making namespace do something too different 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/. --001a11c1bce86c594004f08e87fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 additional template parameter i= mplicitly.

namespace b= lah< typename X >
{
=C2=A0 =C2=A0 =C2=A0class K {};
=C2=A0 =C2=A0 =C2=A0template < class T > class U {};
}

would be translated to=C2=A0

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


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

=C2=A01. namespace are not the appropriate construct for this, they really = are too different and not really encapsulating anything than names;
=C2=A02. there are a lot of potential issues relat= ed to the order of template arguments;
=C2=A03. 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.
=C2=A0 =C2=A0 = =C2=A0What I mean here is basically the same argument that makes Clang deve= lopers 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.
Basically, I want one of the features that the R= eflection group is supposed to look for.
Since that realization, I think that eff= orts should be put to have a new reflection construct instead of making nam= espace do 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/group/std-proposals/<= /a>.
--001a11c1bce86c594004f08e87fe-- .