--047d7b15fb03096d8f04f056157f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi.

   I found a number of situations where the ability to templetize
namespaces would be very useful.

My latest use case is this: I'm writing a library that is configured
through a number of (non-type) template arguments. Such configuration
affects to all the classes of the library. To be more specific, it's a
fault-tolerant library for the aerospace industry where the whole library
is tuned with some integers (some of then related to redundancy due to
ionizing radiation).

The most natural thing would be to put all the classes in a namespace, and
let the namespace be templetized with such arguments.
Moreover, a using namespace with the appropriate arguments would suffice
for all the application. For example:

    using namespace TheLibrary<arg1, arg2, arg3>;

I didn't write the proposal yet, since I'd like to get some feedback.

Thanks,

   Daniel.

ps: The library will be available soon and uses template metaprogramming
based on the arguments.


--=20
Who=92s got the sweetest disposition?
One guess, that=92s who?
Who=92d 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/.

--047d7b15fb03096d8f04f056157f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi.<div><br></div><div>=A0 =A0I found a number of situatio=
ns where the ability to templetize namespaces would be very useful.</div><d=
iv><br></div><div>My latest use case is this: I&#39;m writing a library tha=
t is configured through a number of (non-type) template arguments. Such con=
figuration affects to all the classes of the library. To be more specific, =
it&#39;s a fault-tolerant library for the aerospace industry where the whol=
e library is tuned with some integers (some of then related to redundancy d=
ue to ionizing radiation).</div>
<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>
<div><br></div><div>=A0 =A0 using namespace TheLibrary&lt;arg1, arg2, arg3&=
gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, since I&=
#39;d like to get some feedback.</div><div><br></div><div>Thanks,</div><div=
>
<br></div><div>=A0 =A0Daniel.</div><div><br></div><div>ps: The library will=
 be available soon and uses template metaprogramming based on the arguments=
..</div><div><br clear=3D"all"><div><br></div>-- <br>Who=92s got the sweetes=
t disposition?<br>
One guess, that=92s who?<br>Who=92d never, ever start an argument?<br>Who n=
ever shows a bit of temperament?<br>Who&#39;s never wrong but always right?=
<br>Who&#39;d never dream of starting a fight?<br>Who get stuck with all th=
e bad luck?=20
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b15fb03096d8f04f056157f--

.

------=_Part_188_9001793.1390155383836
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Namespaces differ from classes in that they can be split within and amongst=
=20
translation units.  The definition of a namespace is not required to be the=
=20
same in different translation units.  Multiple namespace definitions of the=
=20
same namespace in the same translation unit are logically merged into one=
=20
(the first is called the original, the following are called extensions).

How do template namespace specialization and template namespace=20
instantiation interact with these new properties that are not present in=20
other template entities?

Also namespaces can contain the following declarations, whereas classes=20
cannot:

explicit-instantiation
explicit-specialization
linkage-speci=EF=AC=81cation
namespace-de=EF=AC=81nition
attribute-declaration
asm-de=EF=AC=81nition
namespace-alias-de=EF=AC=81nition
using-directive
opaque-enum-declaration

Now that all these are possible member declarations of a template entity,=
=20
how are they handled?

Also you need to think about program initialization.  The members of a=20
namespace have a bunch of rules about when they are initialized and in what=
=20
order.  How will these rules interact with template namespace instances?

The best approach for this type of feature would be to put together an=20
experimental compiler extension to gcc or clang that implements template=20
namespaces.  This would shake out all the above issues (and likely more)=20
which you could then use as the basis of a proposal.

On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>
> Hi.
>
>    I found a number of situations where the ability to templetize=20
> namespaces would be very useful.
>
> My latest use case is this: I'm writing a library that is configured=20
> through a number of (non-type) template arguments. Such configuration=20
> affects to all the classes of the library. To be more specific, it's a=20
> fault-tolerant library for the aerospace industry where the whole library=
=20
> is tuned with some integers (some of then related to redundancy due to=20
> ionizing radiation).
>
> The most natural thing would be to put all the classes in a namespace, an=
d=20
> let the namespace be templetized with such arguments.
> Moreover, a using namespace with the appropriate arguments would suffice=
=20
> for all the application. For example:
>
>     using namespace TheLibrary<arg1, arg2, arg3>;
>
> I didn't write the proposal yet, since I'd like to get some feedback.
>
> Thanks,
>
>    Daniel.
>
> ps: The library will be available soon and uses template metaprogramming=
=20
> based on the arguments.
>
>
> --=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
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_188_9001793.1390155383836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Namespaces differ from classes in that they can be split w=
ithin and amongst translation units. &nbsp;The definition of a namespace is=
 not required to be the same in different translation units. &nbsp;Multiple=
 namespace definitions of the same namespace in the same translation unit a=
re logically merged into one (the first is called the original, the followi=
ng are called extensions).<div><br></div><div>How do template namespace spe=
cialization and template namespace instantiation interact with these new pr=
operties that are not present in other template entities?</div><div><br></d=
iv><div>Also namespaces can contain the following declarations, whereas cla=
sses cannot:</div><div><br></div><div><div>explicit-instantiation<br></div>=
<div>explicit-specialization</div><div>linkage-speci=EF=AC=81cation</div><d=
iv>namespace-de=EF=AC=81nition</div><div>attribute-declaration<br></div><di=
v>asm-de=EF=AC=81nition<br></div><div>namespace-alias-de=EF=AC=81nition</di=
v><div>using-directive<br></div><div>opaque-enum-declaration<br></div></div=
><div><br></div><div>Now that all these are possible member declarations of=
 a template entity, how are they handled?</div><div><br></div><div>Also you=
 need to think about program initialization. &nbsp;The members of a namespa=
ce have a bunch of rules about when they are initialized and in what order.=
 &nbsp;How will these rules interact with template namespace instances?</di=
v><div><br></div><div>The best approach for this type of feature would be t=
o put together an experimental compiler extension to gcc or clang that impl=
ements template namespaces. &nbsp;This would shake out all the above issues=
 (and likely more) which you could then use as the basis of a proposal.</di=
v><div><br></div><div>On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson=
 . wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi.<=
div><br></div><div>&nbsp; &nbsp;I found a number of situations where the ab=
ility to templetize namespaces would be very useful.</div><div><br></div><d=
iv>My latest use case is this: I'm writing a library that is configured thr=
ough a number of (non-type) template arguments. Such configuration affects =
to all the classes of the library. To be more specific, it's a fault-tolera=
nt library for the aerospace industry where the whole library is tuned with=
 some integers (some of then related to redundancy due to ionizing radiatio=
n).</div>
<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>
<div><br></div><div>&nbsp; &nbsp; using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn't write the proposal yet, since =
I'd like to get some feedback.</div><div><br></div><div>Thanks,</div><div>
<br></div><div>&nbsp; &nbsp;Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who's never wrong but alway=
s right?<br>Who'd never dream of starting a fight?<br>Who get stuck with al=
l the bad luck?=20
</div></div>
</blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_188_9001793.1390155383836--

.

--001a11c204f2eaf18e04f0825d44
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What are the shortcomings of using a class template as a poor-man's
template?

I imagine that the first one is that it must be defined in a single header,
so if the amount of code used internally is large enough it could make it
hard to maintain.The syntax looks like a using-directive, do you also wish
for the lookup changes associated with it? I imagine this to be the case,
right? Can you use the same library in one program with different template
arguments?

Can you provide a small code sample with how it would look like?


On Sun, Jan 19, 2014 at 1:16 PM, Andrew Tomazos <andrewtomazos@gmail.com>wr=
ote:

> Namespaces differ from classes in that they can be split within and
> amongst translation units.  The definition of a namespace is not required
> to be the same in different translation units.  Multiple namespace
> definitions of the same namespace in the same translation unit are
> logically merged into one (the first is called the original, the followin=
g
> are called extensions).
>
> How do template namespace specialization and template namespace
> instantiation interact with these new properties that are not present in
> other template entities?
>
> Also namespaces can contain the following declarations, whereas classes
> cannot:
>
> explicit-instantiation
> explicit-specialization
> linkage-speci=EF=AC=81cation
> namespace-de=EF=AC=81nition
> attribute-declaration
> asm-de=EF=AC=81nition
> namespace-alias-de=EF=AC=81nition
> using-directive
> opaque-enum-declaration
>
> Now that all these are possible member declarations of a template entity,
> how are they handled?
>
> Also you need to think about program initialization.  The members of a
> namespace have a bunch of rules about when they are initialized and in wh=
at
> order.  How will these rules interact with template namespace instances?
>
> The best approach for this type of feature would be to put together an
> experimental compiler extension to gcc or clang that implements template
> namespaces.  This would shake out all the above issues (and likely more)
> which you could then use as the basis of a proposal.
>
> On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>>
>> Hi.
>>
>>    I found a number of situations where the ability to templetize
>> namespaces would be very useful.
>>
>> My latest use case is this: I'm writing a library that is configured
>> through a number of (non-type) template arguments. Such configuration
>> affects to all the classes of the library. To be more specific, it's a
>> fault-tolerant library for the aerospace industry where the whole librar=
y
>> is tuned with some integers (some of then related to redundancy due to
>> ionizing radiation).
>>
>> The most natural thing would be to put all the classes in a namespace,
>> and let the namespace be templetized with such arguments.
>> Moreover, a using namespace with the appropriate arguments would suffice
>> for all the application. For example:
>>
>>     using namespace TheLibrary<arg1, arg2, arg3>;
>>
>> I didn't write the proposal yet, since I'd like to get some feedback.
>>
>> Thanks,
>>
>>    Daniel.
>>
>> ps: The library will be available soon and uses template metaprogramming
>> based on the arguments.
>>
>>
>> --
>> 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?
>>
>  --
>
> ---
> 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

---=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/.

--001a11c204f2eaf18e04f0825d44
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What are the shortcomings of using a class template as a p=
oor-man&#39;s template?<div><br></div><div>I imagine that the first one is =
that it must be defined in a single header, so if the amount of code used i=
nternally is large enough it could make it hard to maintain.The syntax look=
s like a using-directive, do you also wish for the lookup changes associate=
d with it? I imagine this to be the case, right? Can you use the same libra=
ry in one program with different template arguments?</div>
<div><br></div><div>Can you provide a small code sample with how it would l=
ook like?=C2=A0<br></div></div><div class=3D"gmail_extra"><br><br><div clas=
s=3D"gmail_quote">On Sun, Jan 19, 2014 at 1:16 PM, Andrew Tomazos <span dir=
=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Namespaces differ from clas=
ses in that they can be split within and amongst translation units. =C2=A0T=
he definition of a namespace is not required to be the same in different tr=
anslation units. =C2=A0Multiple namespace definitions of the same namespace=
 in the same translation unit are logically merged into one (the first is c=
alled the original, the following are called extensions).<div>
<br></div><div>How do template namespace specialization and template namesp=
ace instantiation interact with these new properties that are not present i=
n other template entities?</div><div><br></div><div>Also namespaces can con=
tain the following declarations, whereas classes cannot:</div>
<div><br></div><div><div>explicit-instantiation<br></div><div>explicit-spec=
ialization</div><div>linkage-speci=EF=AC=81cation</div><div>namespace-de=EF=
=AC=81nition</div><div>attribute-declaration<br></div><div>asm-de=EF=AC=81n=
ition<br></div><div>
namespace-alias-de=EF=AC=81nition</div><div>using-directive<br></div><div>o=
paque-enum-declaration<br></div></div><div><br></div><div>Now that all thes=
e are possible member declarations of a template entity, how are they handl=
ed?</div>
<div><br></div><div>Also you need to think about program initialization. =
=C2=A0The members of a namespace have a bunch of rules about when they are =
initialized and in what order. =C2=A0How will these rules interact with tem=
plate namespace instances?</div>
<div><br></div><div>The best approach for this type of feature would be to =
put together an experimental compiler extension to gcc or clang that implem=
ents template namespaces. =C2=A0This would shake out all the above issues (=
and likely more) which you could then use as the basis of a proposal.</div>
<div><div class=3D"h5"><div><br></div><div>On Sunday, January 19, 2014 6:26=
:57 PM UTC+1, dgutson . wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">
Hi.<div><br></div><div>=C2=A0 =C2=A0I found a number of situations where th=
e ability to templetize namespaces would be very useful.</div><div><br></di=
v><div>My latest use case is this: I&#39;m writing a library that is config=
ured through a number of (non-type) template arguments. Such configuration =
affects to all the classes of the library. To be more specific, it&#39;s a =
fault-tolerant library for the aerospace industry where the whole library i=
s tuned with some integers (some of then related to redundancy due to ioniz=
ing radiation).</div>

<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>

<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div><div><br></div><div>Thanks,</di=
v><div>

<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>

One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c204f2eaf18e04f0825d44--

.

--047d7b3a946afc011604f083b9b9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 19, 2014 at 10:16 AM, Andrew Tomazos <andrewtomazos@gmail.com>w=
rote:

> Namespaces differ from classes in that they can be split within and
> amongst translation units.  The definition of a namespace is not required
> to be the same in different translation units.  Multiple namespace
> definitions of the same namespace in the same translation unit are
> logically merged into one (the first is called the original, the followin=
g
> are called extensions).
>
> How do template namespace specialization and template namespace
> instantiation interact with these new properties that are not present in
> other template entities?
>
> Also namespaces can contain the following declarations, whereas classes
> cannot:
>
> explicit-instantiation
> explicit-specialization
> linkage-speci=EF=AC=81cation
> namespace-de=EF=AC=81nition
> attribute-declaration
> asm-de=EF=AC=81nition
> namespace-alias-de=EF=AC=81nition
> using-directive
> opaque-enum-declaration
>
> Now that all these are possible member declarations of a template entity,
> how are they handled?
>
> Also you need to think about program initialization.  The members of a
> namespace have a bunch of rules about when they are initialized and in wh=
at
> order.  How will these rules interact with template namespace instances?
>
> The best approach for this type of feature would be to put together an
> experimental compiler extension to gcc or clang that implements template
> namespaces.  This would shake out all the above issues (and likely more)
> which you could then use as the basis of a proposal.
>

In addition to the above list, a proposal on this would need to consider
whether namespace templates could support explicit specializations, partial
specializations, and explicit instantiations (both for themselves and for
their members).


> On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>>
>> Hi.
>>
>>    I found a number of situations where the ability to templetize
>> namespaces would be very useful.
>>
>> My latest use case is this: I'm writing a library that is configured
>> through a number of (non-type) template arguments. Such configuration
>> affects to all the classes of the library. To be more specific, it's a
>> fault-tolerant library for the aerospace industry where the whole librar=
y
>> is tuned with some integers (some of then related to redundancy due to
>> ionizing radiation).
>>
>> The most natural thing would be to put all the classes in a namespace,
>> and let the namespace be templetized with such arguments.
>> Moreover, a using namespace with the appropriate arguments would suffice
>> for all the application. For example:
>>
>>     using namespace TheLibrary<arg1, arg2, arg3>;
>>
>> I didn't write the proposal yet, since I'd like to get some feedback.
>>
>
I think this feature would have value, and seems worth putting before the
committee.


> Thanks,
>>
>>    Daniel.
>>
>> ps: The library will be available soon and uses template metaprogramming
>> based on the arguments.
>>
>>
>> --
>> 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?
>>
>  --
>
> ---
> 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

---=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/.

--047d7b3a946afc011604f083b9b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jan 19, 2014 at 10:16 AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Namespaces differ from clas=
ses in that they can be split within and amongst translation units. =C2=A0T=
he definition of a namespace is not required to be the same in different tr=
anslation units. =C2=A0Multiple namespace definitions of the same namespace=
 in the same translation unit are logically merged into one (the first is c=
alled the original, the following are called extensions).<div>
<br></div><div>How do template namespace specialization and template namesp=
ace instantiation interact with these new properties that are not present i=
n other template entities?</div><div><br></div><div>Also namespaces can con=
tain the following declarations, whereas classes cannot:</div>
<div><br></div><div><div>explicit-instantiation<br></div><div>explicit-spec=
ialization</div><div>linkage-speci=EF=AC=81cation</div><div>namespace-de=EF=
=AC=81nition</div><div>attribute-declaration<br></div><div>asm-de=EF=AC=81n=
ition<br></div><div>
namespace-alias-de=EF=AC=81nition</div><div>using-directive<br></div><div>o=
paque-enum-declaration<br></div></div><div><br></div><div>Now that all thes=
e are possible member declarations of a template entity, how are they handl=
ed?</div>
<div><br></div><div>Also you need to think about program initialization. =
=C2=A0The members of a namespace have a bunch of rules about when they are =
initialized and in what order. =C2=A0How will these rules interact with tem=
plate namespace instances?</div>
<div><br></div><div>The best approach for this type of feature would be to =
put together an experimental compiler extension to gcc or clang that implem=
ents template namespaces. =C2=A0This would shake out all the above issues (=
and likely more) which you could then use as the basis of a proposal.</div>
</div></blockquote><div><br></div><div>In addition to the above list, a pro=
posal on this would need to consider whether namespace templates could supp=
ort explicit specializations, partial specializations, and explicit instant=
iations (both for themselves and for their members).</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"h5"><div>On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi.<div><br></div><div>=C2=A0 =C2=A0I found a number of si=
tuations where the ability to templetize namespaces would be very useful.</=
div><div><br></div><div>My latest use case is this: I&#39;m writing a libra=
ry that is configured through a number of (non-type) template arguments. Su=
ch configuration affects to all the classes of the library. To be more spec=
ific, it&#39;s a fault-tolerant library for the aerospace industry where th=
e whole library is tuned with some integers (some of then related to redund=
ancy due to ionizing radiation).</div>

<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>

<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div></div></blockquote></div></div>=
</div>
</div></blockquote><div><br></div><div>I think this feature would have valu=
e, and seems worth putting before the committee.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"h5"><div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>Thanks,</div><div>
<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>

One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5=
">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a946afc011604f083b9b9--

.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">I had the exact same ideas few =
months ago after finding myself doing generic library which all types would=
 depend on the same type,</div><div class=3D"gmail_extra">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.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">namespace b=
lah&lt; typename X &gt;</div><div class=3D"gmail_extra">{</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0class K {};</div><div class=3D"gmail_e=
xtra">=C2=A0 =C2=A0 =C2=A0template &lt; class T &gt; class U {};</div>
<div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></div><div=
 class=3D"gmail_extra">would be translated to=C2=A0</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">namespace blah</div><div clas=
s=3D"gmail_extra">
{</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 template&lt; typename X &gt=
;</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 class K {};</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 template&lt; typename X, class T &gt; class =
U {};</div><div class=3D"gmail_extra">
}</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">However, after weeks of thinking about thi=
s I concluded that:</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">
=C2=A01. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv class=3D"gmail_extra">=C2=A02. there are a lot of potential issues relat=
ed to the order of template arguments;</div>
<div class=3D"gmail_extra">=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.</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =
=C2=A0What I mean here is basically the same argument that makes Clang deve=
lopers avoid anonymous namespaces.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Also, I bel=
ieve that the real thing I do want when I&#39;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.</div>
<div class=3D"gmail_extra">Basically, I want one of the features that the R=
eflection group is supposed to look for.</div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">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&#39;s initial use.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c1bce86c594004f08e87fe--

.

--bcaec52beba5b2dc0304f0d49670
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 19, 2014 at 3:16 PM, Andrew Tomazos <andrewtomazos@gmail.com>wr=
ote:

> Namespaces differ from classes in that they can be split within and
> amongst translation units.  The definition of a namespace is not required
> to be the same in different translation units.  Multiple namespace
> definitions of the same namespace in the same translation unit are
> logically merged into one (the first is called the original, the followin=
g
> are called extensions).
>
> How do template namespace specialization and template namespace
> instantiation interact with these new properties that are not present in
> other template entities?
>
> Also namespaces can contain the following declarations, whereas classes
> cannot:
>
> explicit-instantiation
> explicit-specialization
> linkage-speci=EF=AC=81cation
> namespace-de=EF=AC=81nition
> attribute-declaration
> asm-de=EF=AC=81nition
> namespace-alias-de=EF=AC=81nition
> using-directive
> opaque-enum-declaration
>
> Now that all these are possible member declarations of a template entity,
> how are they handled?
>
> Also you need to think about program initialization.  The members of a
> namespace have a bunch of rules about when they are initialized and in wh=
at
> order.  How will these rules interact with template namespace instances?
>

I understand that, in terms of a standard, all these considerations have to
be taken into account. That's why I call for help here. Please note that
the very concrete problem I'm referring to still holds and IMHO is
relevant. I kindly invite you that, if you agree, begin drawing with me the
possible rules for addressing all the points that you mentioned.


>
> The best approach for this type of feature would be to put together an
> experimental compiler extension to gcc or clang that implements template
> namespaces.  This would shake out all the above issues (and likely more)
> which you could then use as the basis of a proposal.
>

Despite I was a gcc maintainer in the past, I don't have the resources for
a full fledged implementation of this (specially since I mostly maintained
the ARM backend). Nevertheless, I'll see what I can do with a plugin to get
a proof-of-concept by using a template class to mimick the semantic of a
template namespace. My initial idea is that the original template will be
translated by the plugin as a base class, and the extensions as derived
classes in a fixed order of inheritance.
But please, still consider my call for help while I manage to try a plugin
like this.

Thanks,

   Daniel.


>
> On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>>
>> Hi.
>>
>>    I found a number of situations where the ability to templetize
>> namespaces would be very useful.
>>
>> My latest use case is this: I'm writing a library that is configured
>> through a number of (non-type) template arguments. Such configuration
>> affects to all the classes of the library. To be more specific, it's a
>> fault-tolerant library for the aerospace industry where the whole librar=
y
>> is tuned with some integers (some of then related to redundancy due to
>> ionizing radiation).
>>
>> The most natural thing would be to put all the classes in a namespace,
>> and let the namespace be templetized with such arguments.
>> Moreover, a using namespace with the appropriate arguments would suffice
>> for all the application. For example:
>>
>>     using namespace TheLibrary<arg1, arg2, arg3>;
>>
>> I didn't write the proposal yet, since I'd like to get some feedback.
>>
>> Thanks,
>>
>>    Daniel.
>>
>> ps: The library will be available soon and uses template metaprogramming
>> based on the arguments.
>>
>>
>> --
>> 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?
>>
>  --
>
> ---
> 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=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
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/.

--bcaec52beba5b2dc0304f0d49670
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Jan 19, 2014 at 3:16 PM, Andrew Tomazos <span dir=3D"ltr">&=
lt;<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomaz=
os@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Namespaces differ from clas=
ses in that they can be split within and amongst translation units. =C2=A0T=
he definition of a namespace is not required to be the same in different tr=
anslation units. =C2=A0Multiple namespace definitions of the same namespace=
 in the same translation unit are logically merged into one (the first is c=
alled the original, the following are called extensions).<div>
<br></div><div>How do template namespace specialization and template namesp=
ace instantiation interact with these new properties that are not present i=
n other template entities?</div><div><br></div><div>Also namespaces can con=
tain the following declarations, whereas classes cannot:</div>
<div><br></div><div><div>explicit-instantiation<br></div><div>explicit-spec=
ialization</div><div>linkage-speci=EF=AC=81cation</div><div>namespace-de=EF=
=AC=81nition</div><div>attribute-declaration<br></div><div>asm-de=EF=AC=81n=
ition<br></div><div>
namespace-alias-de=EF=AC=81nition</div><div>using-directive<br></div><div>o=
paque-enum-declaration<br></div></div><div><br></div><div>Now that all thes=
e are possible member declarations of a template entity, how are they handl=
ed?</div>
<div><br></div><div>Also you need to think about program initialization. =
=C2=A0The members of a namespace have a bunch of rules about when they are =
initialized and in what order. =C2=A0How will these rules interact with tem=
plate namespace instances?</div>
</div></blockquote><div><br></div><div>I understand that, in terms of a sta=
ndard, all these considerations have to be taken into account. That&#39;s w=
hy I call for help here. Please note that the very concrete problem I&#39;m=
 referring to still holds and IMHO is relevant. I kindly invite you that, i=
f you agree, begin drawing with me the possible rules for addressing all th=
e points that you mentioned.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><=
/div><div>The best approach for this type of feature would be to put togeth=
er an experimental compiler extension to gcc or clang that implements templ=
ate namespaces. =C2=A0This would shake out all the above issues (and likely=
 more) which you could then use as the basis of a proposal.</div>
</div></blockquote><div><br></div><div>Despite I was a gcc maintainer in th=
e past, I don&#39;t have the resources for a full fledged implementation of=
 this (specially since I mostly maintained the ARM backend). Nevertheless, =
I&#39;ll see what I can do with a plugin to get a proof-of-concept by using=
 a template class to mimick the semantic of a template namespace. My initia=
l idea is that the original template will be translated by the plugin as a =
base class, and the extensions as derived classes in a fixed order of inher=
itance.</div>
<div>But please, still consider my call for help while I manage to try a pl=
ugin like this.</div><div><br></div><div>Thanks,</div><div><br></div><div>=
=C2=A0 =C2=A0Daniel.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"h5"><div><br></div><div>On Sunday, Janu=
ary 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">
<div dir=3D"ltr">Hi.<div><br></div><div>=C2=A0 =C2=A0I found a number of si=
tuations where the ability to templetize namespaces would be very useful.</=
div><div><br></div><div>My latest use case is this: I&#39;m writing a libra=
ry that is configured through a number of (non-type) template arguments. Su=
ch configuration affects to all the classes of the library. To be more spec=
ific, it&#39;s a fault-tolerant library for the aerospace industry where th=
e whole library is tuned with some integers (some of then related to redund=
ancy due to ionizing radiation).</div>

<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>

<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div><div><br></div><div>Thanks,</di=
v><div>

<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>

One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div></div></div></div><span class=3D"HOEnZb"><font color=3D"=
#888888">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=80=99s =
who?<br>Who=E2=80=99d never, ever start an argument?<br>Who never shows a b=
it of temperament?<br>
Who&#39;s never wrong but always right?<br>Who&#39;d never dream of startin=
g a fight?<br>Who get stuck with all the bad luck?=20
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec52beba5b2dc0304f0d49670--

.

--e89a8ff1cc026cb46704f0d4e646
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2014 at 7:16 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.or=
g>wrote:

> What are the shortcomings of using a class template as a poor-man's
> template?
>

That was my original approach (and is my idea of the plugin I mentioned in
my previous email).
Please read below.


>
> I imagine that the first one is that it must be defined in a single
> header, so if the amount of code used internally is large enough it could
> make it hard to maintain.
>

That's one of the issues, though the workaround is an awful preprocessor
hack of #including pieces within the class definition:

template <.....args...>
struct MyLibrary
{
    #include "part1.h"
....
    #include "part2.h"
};

Of course every reader of this list will feel the profound disgusting taste
of this solution.

And even so, there's the 'using' problem: we cannot write
  using class MyLibrary<int, int, char, 25u>;

which clearly can be done with namespaces.



> The syntax looks like a using-directive, do you also wish for the lookup
> changes associated with it?
>

Sure.


> I imagine this to be the case, right? Can you use the same library in one
> program with different template arguments?
>

It is not my case. When you use "a" library, you use all of it as a single
entity (despite library classes can be customized individually through
templates too).
I don't foresee the need of instantiating the same library with different
arguments.


>
> Can you provide a small code sample with how it would look like?
>

For exemplification, I will show an ongoing library we are developing (I
insist it is heavily under development).
It's called robusto: robusto.googlecode.com
We are using it for undisclosed situations of ionizing radiation. The
library (intentionally written in C++03 but useful for my example here,
only for illustrative purposes) will provide a number of classes that
provide sparse redundancy data. Two arguments rule the tuning of the
library: the "distance" of the data, and the number of copies of each data
(it's sparse since ionizing radiation has "regional" effects); the
algorithms that apply to all the copies will be implemented with template
metaprogramming (it's currently fixed in 3 copies). I'm not going to
discuss here why such tuning configuration will apply for all the data
types, nor any other reason of the library design. I'm bringing it here for
the sake of the discussion.
I'd need  two things: 1) not to repeat all the two tuning configuration
template arguments in all the classes, 2) be able to bring the classes of
the specialized library to the scope that uses them with a using directive.

Exemplifying:

template <uint32_t Distance, uint32_t Copies>
namespace NSRobusto
{
    template <class T>
    class Class1
    {
        ...
    };

    template <class T>
    class Class2
    {
       ...
    };
}

// Then, in all the user-side code:
using namespace NSRobusto<4u, 3u>;

Class1<int> c1int;
Class2<char> c2char;

What happens if another translation unit instantiates the namespace with
other arguments?
I think that c1int and c2char should be name-mangled according to the using
namespace affecting them, so no linking clash should occur.
Please, get the token to continue the discussion :-) I already typed too
much.

   Daniel.


>
>
> On Sun, Jan 19, 2014 at 1:16 PM, Andrew Tomazos <andrewtomazos@gmail.com>=
wrote:
>
>> Namespaces differ from classes in that they can be split within and
>> amongst translation units.  The definition of a namespace is not require=
d
>> to be the same in different translation units.  Multiple namespace
>> definitions of the same namespace in the same translation unit are
>> logically merged into one (the first is called the original, the followi=
ng
>> are called extensions).
>>
>> How do template namespace specialization and template namespace
>> instantiation interact with these new properties that are not present in
>> other template entities?
>>
>> Also namespaces can contain the following declarations, whereas classes
>> cannot:
>>
>> explicit-instantiation
>> explicit-specialization
>> linkage-speci=EF=AC=81cation
>> namespace-de=EF=AC=81nition
>> attribute-declaration
>> asm-de=EF=AC=81nition
>> namespace-alias-de=EF=AC=81nition
>> using-directive
>> opaque-enum-declaration
>>
>> Now that all these are possible member declarations of a template entity=
,
>> how are they handled?
>>
>> Also you need to think about program initialization.  The members of a
>> namespace have a bunch of rules about when they are initialized and in w=
hat
>> order.  How will these rules interact with template namespace instances?
>>
>> The best approach for this type of feature would be to put together an
>> experimental compiler extension to gcc or clang that implements template
>> namespaces.  This would shake out all the above issues (and likely more)
>> which you could then use as the basis of a proposal.
>>
>> On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>>>
>>> Hi.
>>>
>>>    I found a number of situations where the ability to templetize
>>> namespaces would be very useful.
>>>
>>> My latest use case is this: I'm writing a library that is configured
>>> through a number of (non-type) template arguments. Such configuration
>>> affects to all the classes of the library. To be more specific, it's a
>>> fault-tolerant library for the aerospace industry where the whole libra=
ry
>>> is tuned with some integers (some of then related to redundancy due to
>>> ionizing radiation).
>>>
>>> The most natural thing would be to put all the classes in a namespace,
>>> and let the namespace be templetized with such arguments.
>>> Moreover, a using namespace with the appropriate arguments would suffic=
e
>>> for all the application. For example:
>>>
>>>     using namespace TheLibrary<arg1, arg2, arg3>;
>>>
>>> I didn't write the proposal yet, since I'd like to get some feedback.
>>>
>>> Thanks,
>>>
>>>    Daniel.
>>>
>>> ps: The library will be available soon and uses template metaprogrammin=
g
>>> based on the arguments.
>>>
>>>
>>> --
>>> 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?
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>  --
>
> ---
> 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=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
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/.

--e89a8ff1cc026cb46704f0d4e646
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jan 21, 2014 at 7:16 PM, David Rodr=C3=ADguez Ibeas <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@=
ieee.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">What are the shortcomings of using a clas=
s template as a poor-man&#39;s template?</div>
</blockquote><div><br></div><div>That was my original approach (and is my i=
dea of the plugin I mentioned in my previous email).</div><div>Please read =
below.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div><br></div><div>I imagine that the first one is that i=
t must be defined in a single header, so if the amount of code used interna=
lly is large enough it could make it hard to maintain.</div></div></blockqu=
ote>
<div><br></div><div>That&#39;s one of the issues, though the workaround is =
an awful preprocessor hack of #including pieces within the class definition=
:</div><div><br></div><div>template &lt;.....args...&gt;</div><div>struct M=
yLibrary</div>
<div>{</div><div>=C2=A0 =C2=A0 #include &quot;part1.h&quot;</div><div>...</=
div><div><div>=C2=A0 =C2=A0 #include &quot;part2.h&quot;</div></div><div>};=
</div><div><br></div><div>Of course every reader of this list will feel the=
 profound disgusting taste of this solution.</div>
<div><br></div><div>And even so, there&#39;s the &#39;using&#39; problem: w=
e cannot write</div><div>=C2=A0 using class MyLibrary&lt;int, int, char, 25=
u&gt;;</div><div><br></div><div>which clearly can be done with namespaces.<=
/div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>The =
syntax looks like a using-directive, do you also wish for the lookup change=
s associated with it?</div>
</div></blockquote><div><br></div><div>Sure.</div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><div> I imagine this to be the case, right? Can you use th=
e same library in one program with different template arguments?</div></div=
></blockquote><div><br></div><div>It is not my case. When you use &quot;a&q=
uot; library, you use all of it as a single entity (despite library classes=
 can be customized individually through templates too).</div>
<div>I don&#39;t foresee the need of instantiating the same library with di=
fferent arguments.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div><br></div><div>Can you provide a small code sample with how it would l=
ook like?=C2=A0<br></div></div></blockquote><div><br></div><div>For exempli=
fication, I will show an ongoing library we are developing (I insist it is =
heavily under development).</div>
<div>It&#39;s called robusto: <a href=3D"http://robusto.googlecode.com">rob=
usto.googlecode.com</a></div><div>We are using it for undisclosed situation=
s of ionizing radiation. The library (intentionally written in C++03 but us=
eful for my example here, only for illustrative purposes) will provide a nu=
mber of classes that provide sparse redundancy data. Two arguments rule the=
 tuning of the library: the &quot;distance&quot; of the data, and the numbe=
r of copies of each data (it&#39;s sparse since ionizing radiation has &quo=
t;regional&quot; effects); the algorithms that apply to all the copies will=
 be implemented with template metaprogramming (it&#39;s currently fixed in =
3 copies). I&#39;m not going to discuss here why such tuning configuration =
will apply for all the data types, nor any other reason of the library desi=
gn. I&#39;m bringing it here for the sake of the discussion.</div>
<div>I&#39;d need =C2=A0two things: 1) not to repeat all the two tuning con=
figuration template arguments in all the classes, 2) be able to bring the c=
lasses of the specialized library to the scope that uses them with a using =
directive.</div>
<div><br></div><div>Exemplifying:</div><div><br></div><div>template &lt;uin=
t32_t Distance, uint32_t Copies&gt;</div><div>namespace NSRobusto</div><div=
>{</div><div>=C2=A0 =C2=A0 template &lt;class T&gt;</div><div>=C2=A0 =C2=A0=
 class Class1</div>
<div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...</div><div>=
=C2=A0 =C2=A0 };</div><div><br></div><div>=C2=A0 =C2=A0 template &lt;class =
T&gt;</div><div>=C2=A0 =C2=A0 class Class2</div><div>=C2=A0 =C2=A0 {</div><=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0...</div><div>=C2=A0 =C2=A0 };</div><div>}</=
div><div><br></div><div>
// Then, in all the user-side code:</div><div>using namespace NSRobusto&lt;=
4u, 3u&gt;;</div><div><br></div><div>Class1&lt;int&gt; c1int;</div><div>Cla=
ss2&lt;char&gt; c2char;</div><div><br></div><div>What happens if another tr=
anslation unit instantiates the namespace with other arguments?</div>
<div>I think that c1int and c2char should be name-mangled according to the =
using namespace affecting them, so no linking clash should occur.<br></div>=
<div>Please, get the token to continue the discussion :-) I already typed t=
oo much.</div>
<div><br></div><div>=C2=A0 =C2=A0Daniel.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr">
<div></div></div><div class=3D""><div class=3D"h5"><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Sun, Jan 19, 2014 at 1:16 PM, Andr=
ew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com"=
 target=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">Namespaces differ from classes in that th=
ey can be split within and amongst translation units. =C2=A0The definition =
of a namespace is not required to be the same in different translation unit=
s. =C2=A0Multiple namespace definitions of the same namespace in the same t=
ranslation unit are logically merged into one (the first is called the orig=
inal, the following are called extensions).<div>

<br></div><div>How do template namespace specialization and template namesp=
ace instantiation interact with these new properties that are not present i=
n other template entities?</div><div><br></div><div>Also namespaces can con=
tain the following declarations, whereas classes cannot:</div>

<div><br></div><div><div>explicit-instantiation<br></div><div>explicit-spec=
ialization</div><div>linkage-speci=EF=AC=81cation</div><div>namespace-de=EF=
=AC=81nition</div><div>attribute-declaration<br></div><div>asm-de=EF=AC=81n=
ition<br></div><div>

namespace-alias-de=EF=AC=81nition</div><div>using-directive<br></div><div>o=
paque-enum-declaration<br></div></div><div><br></div><div>Now that all thes=
e are possible member declarations of a template entity, how are they handl=
ed?</div>

<div><br></div><div>Also you need to think about program initialization. =
=C2=A0The members of a namespace have a bunch of rules about when they are =
initialized and in what order. =C2=A0How will these rules interact with tem=
plate namespace instances?</div>

<div><br></div><div>The best approach for this type of feature would be to =
put together an experimental compiler extension to gcc or clang that implem=
ents template namespaces. =C2=A0This would shake out all the above issues (=
and likely more) which you could then use as the basis of a proposal.</div>

<div><div><div><br></div><div>On Sunday, January 19, 2014 6:26:57 PM UTC+1,=
 dgutson . wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div dir=3D"ltr">
Hi.<div><br></div><div>=C2=A0 =C2=A0I found a number of situations where th=
e ability to templetize namespaces would be very useful.</div><div><br></di=
v><div>My latest use case is this: I&#39;m writing a library that is config=
ured through a number of (non-type) template arguments. Such configuration =
affects to all the classes of the library. To be more specific, it&#39;s a =
fault-tolerant library for the aerospace industry where the whole library i=
s tuned with some integers (some of then related to redundancy due to ioniz=
ing radiation).</div>


<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>


<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div><div><br></div><div>Thanks,</di=
v><div>


<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>


One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div></div></div></div><div><div>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=80=99s wh=
o?<br>Who=E2=80=99d never, ever start an argument?<br>Who never shows a bit=
 of temperament?<br>Who&#39;s never wrong but always right?<br>
Who&#39;d never dream of starting a fight?<br>Who get stuck with all the ba=
d luck?=20
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8ff1cc026cb46704f0d4e646--

.

--bcaec52beba574203504f0d4f4c0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2014 at 8:54 PM, Richard Smith <richard@metafoo.co.uk>wrote=
:

> On Sun, Jan 19, 2014 at 10:16 AM, Andrew Tomazos <andrewtomazos@gmail.com=
>wrote:
>
>> Namespaces differ from classes in that they can be split within and
>> amongst translation units.  The definition of a namespace is not require=
d
>> to be the same in different translation units.  Multiple namespace
>> definitions of the same namespace in the same translation unit are
>> logically merged into one (the first is called the original, the followi=
ng
>> are called extensions).
>>
>> How do template namespace specialization and template namespace
>> instantiation interact with these new properties that are not present in
>> other template entities?
>>
>> Also namespaces can contain the following declarations, whereas classes
>> cannot:
>>
>> explicit-instantiation
>> explicit-specialization
>> linkage-speci=EF=AC=81cation
>> namespace-de=EF=AC=81nition
>> attribute-declaration
>> asm-de=EF=AC=81nition
>> namespace-alias-de=EF=AC=81nition
>> using-directive
>> opaque-enum-declaration
>>
>> Now that all these are possible member declarations of a template entity=
,
>> how are they handled?
>>
>> Also you need to think about program initialization.  The members of a
>> namespace have a bunch of rules about when they are initialized and in w=
hat
>> order.  How will these rules interact with template namespace instances?
>>
>> The best approach for this type of feature would be to put together an
>> experimental compiler extension to gcc or clang that implements template
>> namespaces.  This would shake out all the above issues (and likely more)
>> which you could then use as the basis of a proposal.
>>
>
> In addition to the above list, a proposal on this would need to consider
> whether namespace templates could support explicit specializations, parti=
al
> specializations, and explicit instantiations (both for themselves and for
> their members).
>

Maybe funny things could be done with this and template metaprogramming:
template namespaces recursively instantiating themselves.
However, I'm not sure if new inventions would arise not done before with
template classes.


>
>
>> On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:
>>>
>>> Hi.
>>>
>>>    I found a number of situations where the ability to templetize
>>> namespaces would be very useful.
>>>
>>> My latest use case is this: I'm writing a library that is configured
>>> through a number of (non-type) template arguments. Such configuration
>>> affects to all the classes of the library. To be more specific, it's a
>>> fault-tolerant library for the aerospace industry where the whole libra=
ry
>>> is tuned with some integers (some of then related to redundancy due to
>>> ionizing radiation).
>>>
>>> The most natural thing would be to put all the classes in a namespace,
>>> and let the namespace be templetized with such arguments.
>>> Moreover, a using namespace with the appropriate arguments would suffic=
e
>>> for all the application. For example:
>>>
>>>     using namespace TheLibrary<arg1, arg2, arg3>;
>>>
>>> I didn't write the proposal yet, since I'd like to get some feedback.
>>>
>>
> I think this feature would have value, and seems worth putting before the
> committee.
>
>
>> Thanks,
>>>
>>>    Daniel.
>>>
>>> ps: The library will be available soon and uses template metaprogrammin=
g
>>> based on the arguments.
>>>
>>>
>>> --
>>> 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?
>>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>  --
>
> ---
> 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=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
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/.

--bcaec52beba574203504f0d4f4c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jan 21, 2014 at 8:54 PM, Richard Smith <span dir=3D"ltr">&l=
t;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafo=
o.co.uk</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Sun, Jan 19, 2014 at 10:16 =
AM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gm=
ail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br=
>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Namespaces differ from clas=
ses in that they can be split within and amongst translation units. =C2=A0T=
he definition of a namespace is not required to be the same in different tr=
anslation units. =C2=A0Multiple namespace definitions of the same namespace=
 in the same translation unit are logically merged into one (the first is c=
alled the original, the following are called extensions).<div>

<br></div><div>How do template namespace specialization and template namesp=
ace instantiation interact with these new properties that are not present i=
n other template entities?</div><div><br></div><div>Also namespaces can con=
tain the following declarations, whereas classes cannot:</div>

<div><br></div><div><div>explicit-instantiation<br></div><div>explicit-spec=
ialization</div><div>linkage-speci=EF=AC=81cation</div><div>namespace-de=EF=
=AC=81nition</div><div>attribute-declaration<br></div><div>asm-de=EF=AC=81n=
ition<br></div><div>

namespace-alias-de=EF=AC=81nition</div><div>using-directive<br></div><div>o=
paque-enum-declaration<br></div></div><div><br></div><div>Now that all thes=
e are possible member declarations of a template entity, how are they handl=
ed?</div>

<div><br></div><div>Also you need to think about program initialization. =
=C2=A0The members of a namespace have a bunch of rules about when they are =
initialized and in what order. =C2=A0How will these rules interact with tem=
plate namespace instances?</div>

<div><br></div><div>The best approach for this type of feature would be to =
put together an experimental compiler extension to gcc or clang that implem=
ents template namespaces. =C2=A0This would shake out all the above issues (=
and likely more) which you could then use as the basis of a proposal.</div>

</div></blockquote><div><br></div></div><div>In addition to the above list,=
 a proposal on this would need to consider whether namespace templates coul=
d support explicit specializations, partial specializations, and explicit i=
nstantiations (both for themselves and for their members).</div>
</div></div></div></blockquote><div><br></div><div>Maybe funny things could=
 be done with this and template metaprogramming: template namespaces recurs=
ively instantiating themselves.</div><div>However, I&#39;m not sure if new =
inventions would arise not done before with template classes.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D"im">
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
<div>On Sunday, January 19, 2014 6:26:57 PM UTC+1, dgutson . wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Hi.<div><br></div><div>=C2=A0 =C2=A0I found a number of si=
tuations where the ability to templetize namespaces would be very useful.</=
div><div><br></div><div>My latest use case is this: I&#39;m writing a libra=
ry that is configured through a number of (non-type) template arguments. Su=
ch configuration affects to all the classes of the library. To be more spec=
ific, it&#39;s a fault-tolerant library for the aerospace industry where th=
e whole library is tuned with some integers (some of then related to redund=
ancy due to ionizing radiation).</div>


<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>


<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div></div></blockquote></div></div>=
</div>

</div></blockquote><div><br></div></div><div>I think this feature would hav=
e value, and seems worth putting before the committee.</div><div class=3D"i=
m"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div><div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>Thanks,</div><div>
<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>


One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div></div></div></div><div><div>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div></div><br></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Who=E2=80=99s got the sweetest disposition?<br>One guess, that=E2=80=99s wh=
o?<br>Who=E2=80=99d never, ever start an argument?<br>Who never shows a bit=
 of temperament?<br>Who&#39;s never wrong but always right?<br>
Who&#39;d never dream of starting a fight?<br>Who get stuck with all the ba=
d luck?=20
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec52beba574203504f0d4f4c0--

.

--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 <mjklaim@gmail.com>=
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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=EBl Lamotte <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">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,</div>
<div class=3D"gmail_extra">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.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">namespace b=
lah&lt; typename X &gt;</div><div class=3D"gmail_extra">{</div><div class=
=3D"gmail_extra">&nbsp; &nbsp; &nbsp;class K {};</div><div class=3D"gmail_e=
xtra">&nbsp; &nbsp; &nbsp;template &lt; class T &gt; class U {};</div>

<div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></div><div=
 class=3D"gmail_extra">would be translated to&nbsp;</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">namespace blah</div><div clas=
s=3D"gmail_extra">

{</div><div class=3D"gmail_extra">&nbsp; &nbsp; template&lt; typename X &gt=
;</div><div class=3D"gmail_extra">&nbsp; &nbsp; class K {};</div><div class=
=3D"gmail_extra">&nbsp; &nbsp; template&lt; typename X, class T &gt; class =
U {};</div><div class=3D"gmail_extra">

}</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">However, after weeks of thinking about thi=
s I concluded that:</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">

&nbsp;1. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv class=3D"gmail_extra">&nbsp;2. there are a lot of potential issues relat=
ed to the order of template arguments;</div>
</div></blockquote><div><br></div><div>Please elaborate about the last two =
points.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">&nbsp;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.</div></div></blockquote><div><br></div><div>I =
don&#39;t find this issue different than any other template declaration, fo=
r example a nested class of a template class.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a">&nbsp; &nbsp; &nbsp;What I mean here is basically the same argument that=
 makes Clang developers avoid anonymous namespaces.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Also, I bel=
ieve that the real thing I do want when I&#39;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.</div>
</div></blockquote><div><br></div><div>We agree on that.</div><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">Basically, I want one of the features that the R=
eflection group is supposed to look for.</div></div></blockquote><div><br><=
/div><div>I&#39;m working on&nbsp;<a href=3D"http://statement-templates.goo=
glecode.com">statement-templates.googlecode.com</a> but that&#39;s somethin=
g I will post in this list later.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><br></div>
<div class=3D"gmail_extra">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&#39;s initial use.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div></div><div class=3D""><div class=3D"h5"=
>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Who&rsquo;s got the sweetest disposition?<br>One guess, that&rsquo;s who?<b=
r>Who&rsquo;d never, ever start an argument?<br>Who never shows a bit of te=
mperament?<br>Who&#39;s never wrong but always right?<br>
Who&#39;d never dream of starting a fight?<br>Who get stuck with all the ba=
d luck?=20
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec52beba504dba004f0d5006d--

.

------=_Part_1447_1681364554.1414133252013
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Daniel,

I agree with you.

PF, ncomputers.org

Am Sonntag, 19. Januar 2014 11:26:57 UTC-6 schrieb dgutson:
>
> Hi.
>
>    I found a number of situations where the ability to templetize=20
> namespaces would be very useful.
>
> My latest use case is this: I'm writing a library that is configured=20
> through a number of (non-type) template arguments. Such configuration=20
> affects to all the classes of the library. To be more specific, it's a=20
> fault-tolerant library for the aerospace industry where the whole library=
=20
> is tuned with some integers (some of then related to redundancy due to=20
> ionizing radiation).
>
> The most natural thing would be to put all the classes in a namespace, an=
d=20
> let the namespace be templetized with such arguments.
> Moreover, a using namespace with the appropriate arguments would suffice=
=20
> for all the application. For example:
>
>     using namespace TheLibrary<arg1, arg2, arg3>;
>
> I didn't write the proposal yet, since I'd like to get some feedback.
>
> Thanks,
>
>    Daniel.
>
> ps: The library will be available soon and uses template metaprogramming=
=20
> based on the arguments.
>
>
> --=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
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_1447_1681364554.1414133252013
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Daniel,<br><br>I agree with you.<br><br>PF, ncomputers.org=
<br><br>Am Sonntag, 19. Januar 2014 11:26:57 UTC-6 schrieb dgutson:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi.<div><br></div><di=
v>&nbsp; &nbsp;I found a number of situations where the ability to templeti=
ze namespaces would be very useful.</div><div><br></div><div>My latest use =
case is this: I'm writing a library that is configured through a number of =
(non-type) template arguments. Such configuration affects to all the classe=
s of the library. To be more specific, it's a fault-tolerant library for th=
e aerospace industry where the whole library is tuned with some integers (s=
ome of then related to redundancy due to ionizing radiation).</div>
<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>
<div><br></div><div>&nbsp; &nbsp; using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn't write the proposal yet, since =
I'd like to get some feedback.</div><div><br></div><div>Thanks,</div><div>
<br></div><div>&nbsp; &nbsp;Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who's never wrong but alway=
s right?<br>Who'd never dream of starting a fight?<br>Who get stuck with al=
l the bad luck?=20
</div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1447_1681364554.1414133252013--

.

--001a1139761cfe7aa7050629c0f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry I didn't see your reply before.

On Sun, Jan 26, 2014 at 1:52 AM, dgutson . <danielgutson@gmail.com> wrote:

> On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail=
..com>
> 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 addition=
al
>> 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 ar=
e
>> 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.
>
>

Basically, namespaces don't have a unique definition and are only affecting
naming.
Therefore, what would be better to template would be something like a
module or a class or a mixin (a class component).



>   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 co=
de.
>>
>
> I don't find this issue different than any other template declaration, fo=
r
> example a nested class of a template class.
>
>

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 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 differ=
ent
>> from it's initial use.
>>
>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>>
>
>
>
> --
> 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?
>
> --
>
> ---
> 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

---=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/.

--001a1139761cfe7aa7050629c0f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry I didn&#39;t see your reply before.<br><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jan 26, 2014 at 1:52 A=
M, dgutson . <span dir=3D"ltr">&lt;<a href=3D"mailto:danielgutson@gmail.com=
" target=3D"_blank">danielgutson@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span class=3D"">On Wed, Jan 22, 2014 at 9:47 AM, Klaim=
 - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a href=3D"mailto:mjklaim@gmail.=
com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">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,</div>
<div class=3D"gmail_extra">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.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">namespace b=
lah&lt; typename X &gt;</div><div class=3D"gmail_extra">{</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0class K {};</div><div class=3D"gmail_e=
xtra">=C2=A0 =C2=A0 =C2=A0template &lt; class T &gt; class U {};</div>

<div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></div><div=
 class=3D"gmail_extra">would be translated to=C2=A0</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra">namespace blah</div><div clas=
s=3D"gmail_extra">

{</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 template&lt; typename X &gt=
;</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 class K {};</div><div class=
=3D"gmail_extra">=C2=A0 =C2=A0 template&lt; typename X, class T &gt; class =
U {};</div><div class=3D"gmail_extra">

}</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br>=
</div><div class=3D"gmail_extra">However, after weeks of thinking about thi=
s I concluded that:</div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">

=C2=A01. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv class=3D"gmail_extra">=C2=A02. there are a lot of potential issues relat=
ed to the order of template arguments;</div>
</div></blockquote><div><br></div></span><div>Please elaborate about the la=
st two points.</div><span class=3D""><div>=C2=A0</div></span></div></div></=
div></blockquote><div><br></div><div>Basically, namespaces don&#39;t have a=
 unique definition and are only affecting naming.</div><div>Therefore, what=
 would be better to template would be something like a module or a class or=
 a mixin (a class component).</div><div><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">=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.</div></div></blockquote><div><br></div></span>=
<div>I don&#39;t find this issue different than any other template declarat=
ion, for example a nested class of a template class.</div><span class=3D"">
<div>=C2=A0</div></span></div></div></div></blockquote><div><br></div><div>=
Yes, it&#39;s a weak point but apparently some people have trouble with thi=
s.</div><div>Not sure if it should be taken into account.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0What I mean here is=
 basically the same argument that makes Clang developers avoid anonymous na=
mespaces.</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Also, I bel=
ieve that the real thing I do want when I&#39;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.</div>
</div></blockquote><div><br></div></span><div>We agree on that.</div><span =
class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">Basically, I want one of the features that the R=
eflection group is supposed to look for.</div></div></blockquote><div><br><=
/div></span><div>I&#39;m working on=C2=A0<a href=3D"http://statement-templa=
tes.googlecode.com" target=3D"_blank">statement-templates.googlecode.com</a=
> but that&#39;s something I will post in this list later.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><br></div>
<div class=3D"gmail_extra">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&#39;s initial use.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div></div></span><span class=3D""><div><div=
>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></span></blockquote></div><span class=3D""><br><br clear=3D"all=
"><div><br></div>-- <br>Who=E2=80=99s got the sweetest disposition?<br>One =
guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<=
br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but alway=
s right?<br>
Who&#39;d never dream of starting a fight?<br>Who get stuck with all the ba=
d luck?=20
</span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1139761cfe7aa7050629c0f2--

.

------=_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<typename Typename>
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 . <daniel...@gmail.com=20
> <javascript:>> wrote:
>
>> On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <mjk...@gmail=
..com=20
>> <javascript:>> 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 <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
>>> 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 <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> 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

<div dir=3D"ltr">I think that templetized templates should be allowed using=
 nested namespaces by classes, for example:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Typename</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> A</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp=
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">namespac=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &=
nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type=
name</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">Variable</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>PF, nco=
mputers<br><br>Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb Klaim - =
Jo=C3=ABl Lamotte:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Sorry I didn't see your reply before.<br><div><br><div class=3D"gmail_=
quote">On Sun, Jan 26, 2014 at 1:52 AM, dgutson . <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"yMFBNKkM8DM=
J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">daniel...@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><span>On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"yMFBNKkM8DMJ" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">mjk...@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>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,</div>
<div>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.</div>
<div><br></div><div>namespace blah&lt; typename X &gt;</div><div>{</div><di=
v>&nbsp; &nbsp; &nbsp;class K {};</div><div>&nbsp; &nbsp; &nbsp;template &l=
t; class T &gt; class U {};</div>

<div>}</div><div><br></div><div>would be translated to&nbsp;</div><div><br>=
</div><div>namespace blah</div><div>

{</div><div>&nbsp; &nbsp; template&lt; typename X &gt;</div><div>&nbsp; &nb=
sp; class K {};</div><div>&nbsp; &nbsp; template&lt; typename X, class T &g=
t; class U {};</div><div>

}</div><div><br></div><div><br></div><div>However, after weeks of thinking =
about this I concluded that:</div><div><br></div><div>

&nbsp;1. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv>&nbsp;2. there are a lot of potential issues related to the order of tem=
plate arguments;</div>
</div></blockquote><div><br></div></span><div>Please elaborate about the la=
st two points.</div><span><div>&nbsp;</div></span></div></div></div></block=
quote><div><br></div><div>Basically, namespaces don't have a unique definit=
ion and are only affecting naming.</div><div>Therefore, what would be bette=
r to template would be something like a module or a class or a mixin (a cla=
ss component).</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
<div dir=3D"ltr">
<div>&nbsp;3. there is a potential issue for reading the code as you need t=
o see the namespace declaration before being able to follow the rest of the=
 code.</div></div></blockquote><div><br></div></span><div>I don't find this=
 issue different than any other template declaration, for example a nested =
class of a template class.</div><span>
<div>&nbsp;</div></span></div></div></div></blockquote><div><br></div><div>=
Yes, it's a weak point but apparently some people have trouble with this.</=
div><div>Not sure if it should be taken into account.</div><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div>&nbsp; &nbsp; &nbsp;What=
 I mean here is basically the same argument that makes Clang developers avo=
id anonymous namespaces.</div>

<div><br></div><div>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.</div>
</div></blockquote><div><br></div></span><div>We agree on that.</div><span>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>Basically, I want one of the features that the Reflection group is sup=
posed to look for.</div></div></blockquote><div><br></div></span><div>I'm w=
orking on&nbsp;<a href=3D"http://statement-templates.googlecode.com" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://statement-templates.googleco=
de.com';return true;" onclick=3D"this.href=3D'http://statement-templates.go=
oglecode.com';return true;">statement-templates.<wbr>googlecode.com</a> but=
 that's something I will post in this list later.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span><div dir=3D"ltr"><div><br></div>
<div>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.</div>
<div><br></div><div><br></div><div><br></div></div></span><span><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
yMFBNKkM8DMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"yMFBNKkM8DMJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></span></blockquote></div><span><br><br clear=3D"all"><div><br>=
</div>-- <br>Who=E2=80=99s got the sweetest disposition?<br>One guess, that=
=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who neve=
r shows a bit of temperament?<br>Who's never wrong but always right?<br>
Who'd never dream of starting a fight?<br>Who get stuck with all the bad lu=
ck?=20
</span></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
yMFBNKkM8DMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"yMFBNKkM8DMJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_217_1200739447.1414166360021--

.

------=_Part_39_1844636445.1417632750378
Content-Type: multipart/alternative;
 boundary="----=_Part_40_1940408946.1417632750380"

------=_Part_40_1940408946.1417632750380
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Templetized is not a word.=20

On Friday, October 24, 2014 10:59:20 AM UTC-5, con...@ncomputers.org wrote:
>
> I think that templetized templates should be allowed using nested=20
> namespaces by classes, for example:
>
> template<typename Typename>
> class A{
>     namespace B{
>         Typename Variable;
>     }
> };
>
> PF, ncomputers
>
> Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb Klaim - Jo=C3=ABl Lam=
otte:
>>
>> 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 <mjk...@gmai=
l.com>=20
>>> 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 t=
o=20
>>>> specify that a whole bunch of types would automatically have an additi=
onal=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=20
>>>> template 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 =
code.
>>>>
>>>
>>> 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, usin=
g=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=
=20
>>> I will post in this list later.
>>> =20
>>>
>>>>
>>>> Since that realization, I think that efforts should be put to have a=
=20
>>>> new reflection construct instead of making namespace do something too=
=20
>>>> different 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=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

---=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_40_1940408946.1417632750380
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Templetized is not a word.&nbsp;<br><br>On Friday, October 24, 2014 10:59:2=
0 AM UTC-5, con...@ncomputers.org wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">I think that templetized templates should be all=
owed using nested namespaces by classes, for example:<br><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"co=
lor:#008">template</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">Typename</span><span style=3D"color:#660">&gt;</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">class</span><s=
pan style=3D"color:#000"> A</span><span style=3D"color:#660">{</span><span =
style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#008">na=
mespace</span><span style=3D"color:#000"> B</span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span=
><span style=3D"color:#606">Typename</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#606">Variable</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"col=
or:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">};</span><span style=3D"color:#000"><br></span></div></code></div><b=
r>PF, ncomputers<br><br>Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb=
 Klaim - Jo=C3=ABl Lamotte:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Sorry I didn't see your reply before.<br><div><br><div class=3D"gm=
ail_quote">On Sun, Jan 26, 2014 at 1:52 AM, dgutson . <span dir=3D"ltr">&lt=
;<a>daniel...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span>On Wed, Jan 22,=
 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt;<a>mjk...=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>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,</div>
<div>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.</div>
<div><br></div><div>namespace blah&lt; typename X &gt;</div><div>{</div><di=
v>&nbsp; &nbsp; &nbsp;class K {};</div><div>&nbsp; &nbsp; &nbsp;template &l=
t; class T &gt; class U {};</div>

<div>}</div><div><br></div><div>would be translated to&nbsp;</div><div><br>=
</div><div>namespace blah</div><div>

{</div><div>&nbsp; &nbsp; template&lt; typename X &gt;</div><div>&nbsp; &nb=
sp; class K {};</div><div>&nbsp; &nbsp; template&lt; typename X, class T &g=
t; class U {};</div><div>

}</div><div><br></div><div><br></div><div>However, after weeks of thinking =
about this I concluded that:</div><div><br></div><div>

&nbsp;1. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv>&nbsp;2. there are a lot of potential issues related to the order of tem=
plate arguments;</div>
</div></blockquote><div><br></div></span><div>Please elaborate about the la=
st two points.</div><span><div>&nbsp;</div></span></div></div></div></block=
quote><div><br></div><div>Basically, namespaces don't have a unique definit=
ion and are only affecting naming.</div><div>Therefore, what would be bette=
r to template would be something like a module or a class or a mixin (a cla=
ss component).</div><div><br></div><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
<div dir=3D"ltr">
<div>&nbsp;3. there is a potential issue for reading the code as you need t=
o see the namespace declaration before being able to follow the rest of the=
 code.</div></div></blockquote><div><br></div></span><div>I don't find this=
 issue different than any other template declaration, for example a nested =
class of a template class.</div><span>
<div>&nbsp;</div></span></div></div></div></blockquote><div><br></div><div>=
Yes, it's a weak point but apparently some people have trouble with this.</=
div><div>Not sure if it should be taken into account.</div><div>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><div>&nbsp; &nbsp; &nbsp;What=
 I mean here is basically the same argument that makes Clang developers avo=
id anonymous namespaces.</div>

<div><br></div><div>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.</div>
</div></blockquote><div><br></div></span><div>We agree on that.</div><span>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>Basically, I want one of the features that the Reflection group is sup=
posed to look for.</div></div></blockquote><div><br></div></span><div>I'm w=
orking on&nbsp;<a href=3D"http://statement-templates.googlecode.com" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://statement-templates.googleco=
de.com';return true;" onclick=3D"this.href=3D'http://statement-templates.go=
oglecode.com';return true;">statement-templates.<wbr>googlecode.com</a> but=
 that's something I will post in this list later.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span><div dir=3D"ltr"><div><br></div>
<div>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.</div>
<div><br></div><div><br></div><div><br></div></div></span><span><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></span></blockquote></div><span><br><br clear=3D"all"><div><br>=
</div>-- <br>Who=E2=80=99s got the sweetest disposition?<br>One guess, that=
=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who neve=
r shows a bit of temperament?<br>Who's never wrong but always right?<br>
Who'd never dream of starting a fight?<br>Who get stuck with all the bad lu=
ck?=20
</span></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div></blockquote>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_40_1940408946.1417632750380--
------=_Part_39_1844636445.1417632750378--

.

--089e0160b7cc491026050956e332
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Neither is pedanitpicated.

On Wed, Dec 3, 2014 at 7:52 PM, <rjwhitt2001@gmail.com> wrote:

> Templetized is not a word.
>
>
> On Friday, October 24, 2014 10:59:20 AM UTC-5, con...@ncomputers.org
> wrote:
>>
>> I think that templetized templates should be allowed using nested
>> namespaces by classes, for example:
>>
>> template<typename Typename>
>> class A{
>>     namespace B{
>>         Typename Variable;
>>     }
>> };
>>
>> PF, ncomputers
>>
>> Am Freitag, 24. Oktober 2014 06:48:09 UTC-5 schrieb Klaim - Jo=C3=ABl La=
motte:
>>>
>>> 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 <mjk...@gma=
il.com
>>>> > 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
>>>>> 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;
>>>>>
>>>>
>>>> Please elaborate about the last two points.
>>>>
>>>>
>>>
>>> Basically, namespaces don't have a unique definition and are only
>>> affecting naming.
>>> Therefore, what would be better to template would be something like a
>>> module or a class or a mixin (a class component).
>>>
>>>
>>>
>>>>   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,
>>>> for example a nested class of a template class.
>>>>
>>>>
>>>
>>> Yes, it's a weak point but apparently some people have trouble with thi=
s.
>>> Not sure if it should be taken into account.
>>>
>>>
>>>>      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, usi=
ng
>>>>> 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
>>>>> 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, sen=
d
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>>>> proposals/.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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?
>>>>
>>>> --
>>>>
>>>> ---
>>>> 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-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>>> proposals/.
>>>>
>>>
>>>  --
>
> ---
> 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

---=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/.

--089e0160b7cc491026050956e332
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Neither is pedanitpicated.</div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Wed, Dec 3, 2014 at 7:52 PM,  <span dir=
=3D"ltr">&lt;<a href=3D"mailto:rjwhitt2001@gmail.com" target=3D"_blank">rjw=
hitt2001@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
Templetized is not a word.=C2=A0<div class=3D"HOEnZb"><div class=3D"h5"><br=
><br>On Friday, October 24, 2014 10:59:20 AM UTC-5, <a href=3D"mailto:con..=
..@ncomputers.org" target=3D"_blank">con...@ncomputers.org</a> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I think that templetized =
templates should be allowed using nested namespaces by classes, for example=
:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#008">template</span><span style=3D"color:#660">=
&lt;</span><span style=3D"color:#008">typename</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Typename</span><span style=3D"color=
:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">class</span><span style=3D"color:#000"> A</span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#008">namespace</span><span style=3D"color:#000"> B</span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#606">Typename</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">Variable</span><span =
style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">};</span><span style=3D"color:#000"><br></sp=
an></div></code></div><br>PF, ncomputers<br><br>Am Freitag, 24. Oktober 201=
4 06:48:09 UTC-5 schrieb Klaim - Jo=C3=ABl Lamotte:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Sorry I didn&#39;t see your reply before.<=
br><div><br><div class=3D"gmail_quote">On Sun, Jan 26, 2014 at 1:52 AM, dgu=
tson . <span dir=3D"ltr">&lt;<a>daniel...@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><span>On Wed, Jan 22, 2014 at 9:47 AM, Klaim - Jo=C3=ABl Lamotte <sp=
an dir=3D"ltr">&lt;<a>mjk...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>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,</div>
<div>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.</div>
<div><br></div><div>namespace blah&lt; typename X &gt;</div><div>{</div><di=
v>=C2=A0 =C2=A0 =C2=A0class K {};</div><div>=C2=A0 =C2=A0 =C2=A0template &l=
t; class T &gt; class U {};</div>

<div>}</div><div><br></div><div>would be translated to=C2=A0</div><div><br>=
</div><div>namespace blah</div><div>

{</div><div>=C2=A0 =C2=A0 template&lt; typename X &gt;</div><div>=C2=A0 =C2=
=A0 class K {};</div><div>=C2=A0 =C2=A0 template&lt; typename X, class T &g=
t; class U {};</div><div>

}</div><div><br></div><div><br></div><div>However, after weeks of thinking =
about this I concluded that:</div><div><br></div><div>

=C2=A01. namespace are not the appropriate construct for this, they really =
are too different and not really encapsulating anything than names;</div><d=
iv>=C2=A02. there are a lot of potential issues related to the order of tem=
plate arguments;</div>
</div></blockquote><div><br></div></span><div>Please elaborate about the la=
st two points.</div><span><div>=C2=A0</div></span></div></div></div></block=
quote><div><br></div><div>Basically, namespaces don&#39;t have a unique def=
inition and are only affecting naming.</div><div>Therefore, what would be b=
etter to template would be something like a module or a class or a mixin (a=
 class component).</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><span><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
<div dir=3D"ltr">
<div>=C2=A03. there is a potential issue for reading the code as you need t=
o see the namespace declaration before being able to follow the rest of the=
 code.</div></div></blockquote><div><br></div></span><div>I don&#39;t find =
this issue different than any other template declaration, for example a nes=
ted class of a template class.</div><span>
<div>=C2=A0</div></span></div></div></div></blockquote><div><br></div><div>=
Yes, it&#39;s a weak point but apparently some people have trouble with thi=
s.</div><div>Not sure if it should be taken into account.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gma=
il_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0 =C2=A0 =C2=A0=
What I mean here is basically the same argument that makes Clang developers=
 avoid anonymous namespaces.</div>

<div><br></div><div>Also, I believe that the real thing I do want when I&#3=
9;m writing these generic libraries is actually to generate a whole bunch o=
f types, using another type as argument of the process to generate the want=
ed types.</div>
</div></blockquote><div><br></div></span><div>We agree on that.</div><span>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div>Basically, I want one of the features that the Reflection group is sup=
posed to look for.</div></div></blockquote><div><br></div></span><div>I&#39=
;m working on=C2=A0<a href=3D"http://statement-templates.googlecode.com" ta=
rget=3D"_blank">statement-templates.<u></u>googlecode.com</a> but that&#39;=
s something I will post in this list later.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span><div dir=3D"ltr"><div><br></div>
<div>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&#39;s initial use.</div>
<div><br></div><div><br></div><div><br></div></div></span><span><div><div>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></span></blockquote></div><span><br><br clear=3D"all"><div><br>=
</div>-- <br>Who=E2=80=99s got the sweetest disposition?<br>One guess, that=
=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argument?<br>Who neve=
r shows a bit of temperament?<br>Who&#39;s never wrong but always right?<br=
>
Who&#39;d never dream of starting a fight?<br>Who get stuck with all the ba=
d luck?=20
</span></div></div><div><div>

<p></p>

-- <br>
=C2=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div></blockquote>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0160b7cc491026050956e332--

.

------=_Part_28340_1358942037.1511957579468
Content-Type: multipart/alternative;
 boundary="----=_Part_28341_1911103968.1511957579468"

------=_Part_28341_1911103968.1511957579468
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Are you still interested in this proposal? I created a new post a few days=
=20
ago and was pointed in the direction of this post. We can continue the=20
discussion here or there - it's up to you. I have addressed a couple of the=
=20
points made on this thread in my thread:

https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/templ=
ated$20namespaces/std-proposals/3MR8IhevevU/HQNEFn5fAwAJ



On Sunday, January 19, 2014 at 5:26:57 PM UTC, dgutson wrote:
>
> Hi.
>
>    I found a number of situations where the ability to templetize=20
> namespaces would be very useful.
>
> My latest use case is this: I'm writing a library that is configured=20
> through a number of (non-type) template arguments. Such configuration=20
> affects to all the classes of the library. To be more specific, it's a=20
> fault-tolerant library for the aerospace industry where the whole library=
=20
> is tuned with some integers (some of then related to redundancy due to=20
> ionizing radiation).
>
> The most natural thing would be to put all the classes in a namespace, an=
d=20
> let the namespace be templetized with such arguments.
> Moreover, a using namespace with the appropriate arguments would suffice=
=20
> for all the application. For example:
>
>     using namespace TheLibrary<arg1, arg2, arg3>;
>
> I didn't write the proposal yet, since I'd like to get some feedback.
>
> Thanks,
>
>    Daniel.
>
> ps: The library will be available soon and uses template metaprogramming=
=20
> based on the arguments.
>
>
> --=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
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/8279ad9d-1e09-4465-a7a5-ace40f9ae464%40isocpp.or=
g.

------=_Part_28341_1911103968.1511957579468
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Are you still interested in this proposal? I created a new=
 post a few days ago and was pointed in the direction of this post. We can =
continue the discussion here or there - it&#39;s up to you. I have addresse=
d a couple of the points made on this thread in my thread:<br><br>https://g=
roups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/templated$20na=
mespaces/std-proposals/3MR8IhevevU/HQNEFn5fAwAJ<br><br><br><br>On Sunday, J=
anuary 19, 2014 at 5:26:57 PM UTC, dgutson wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Hi.<div><br></div><div>=C2=A0 =C2=A0I f=
ound a number of situations where the ability to templetize namespaces woul=
d be very useful.</div><div><br></div><div>My latest use case is this: I&#3=
9;m writing a library that is configured through a number of (non-type) tem=
plate arguments. Such configuration affects to all the classes of the libra=
ry. To be more specific, it&#39;s a fault-tolerant library for the aerospac=
e industry where the whole library is tuned with some integers (some of the=
n related to redundancy due to ionizing radiation).</div>
<div><br></div><div>The most natural thing would be to put all the classes =
in a namespace, and let the namespace be templetized with such arguments.</=
div><div>Moreover, a using namespace with the appropriate arguments would s=
uffice for all the application. For example:</div>
<div><br></div><div>=C2=A0 =C2=A0 using namespace TheLibrary&lt;arg1, arg2,=
 arg3&gt;;</div><div><br></div><div>I didn&#39;t write the proposal yet, si=
nce I&#39;d like to get some feedback.</div><div><br></div><div>Thanks,</di=
v><div>
<br></div><div>=C2=A0 =C2=A0Daniel.</div><div><br></div><div>ps: The librar=
y will be available soon and uses template metaprogramming based on the arg=
uments.</div><div><br clear=3D"all"><div><br></div>-- <br>Who=E2=80=99s got=
 the sweetest disposition?<br>
One guess, that=E2=80=99s who?<br>Who=E2=80=99d never, ever start an argume=
nt?<br>Who never shows a bit of temperament?<br>Who&#39;s never wrong but a=
lways right?<br>Who&#39;d never dream of starting a fight?<br>Who get stuck=
 with all the bad luck?=20
</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8279ad9d-1e09-4465-a7a5-ace40f9ae464%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8279ad9d-1e09-4465-a7a5-ace40f9ae464=
%40isocpp.org</a>.<br />

------=_Part_28341_1911103968.1511957579468--

------=_Part_28340_1358942037.1511957579468--

.