Bengt Gustafsson <bengt.gustafsson@beamways.com> writes:

[...]

| My suggested solution is:
|
| If two things with the same name are found select the name in the most nested
| namespace if the two conflicting namespaces are nested in each other.

For C++11 and beyond, I would like to see fundamental things such as
name lookup rules enjoy stability.  Waking up in the morning and realize
that half of the floor is gone and the living room turned into a
restroom is no fun.

-- Gaby

--

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

.

------=_Part_67_32752966.1378038789386
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don't see the problem as the change I suggest only makes currently=20
erroneous code to become legal and well defined. This is nowhere near=20
removing the floor. Of course, if you can show me a case where curreently=
=20
valid code changes behaviour, that's an entirely different thing.

My motivation was that I don't want to see improved features get worse=20
names than the inferior but older functionality. I would prefer to be able=
=20
to state that I want to use the new feature instead of the old, using the=
=20
logical name.

Even if you can show me that the idea of a disambiguation rule such as the=
=20
one I suggested doesn't work I still think that a mechanism to achieve the=
=20
end goal would be desirable. At this point I don't really know what would=
=20
be best. One naive way would be to use a compiler pragma, but compared to a=
=20
using directive that's very clumsy and error prone.

Den l=F6rdagen den 31:e augusti 2013 kl. 21:16:36 UTC+2 skrev Gabriel Dos=
=20
Reis:
>
> Bengt Gustafsson <bengt.gu...@beamways.com <javascript:>> writes:=20
>
> [...]=20
>
> | My suggested solution is:=20
> |=20
> | If two things with the same name are found select the name in the most=
=20
> nested=20
> | namespace if the two conflicting namespaces are nested in each other.=
=20
>
> For C++11 and beyond, I would like to see fundamental things such as=20
> name lookup rules enjoy stability.  Waking up in the morning and realize=
=20
> that half of the floor is gone and the living room turned into a=20
> restroom is no fun.=20
>
> -- Gaby=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_67_32752966.1378038789386
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don't see the problem as the change I suggest only makes=
 currently erroneous code to become legal and well defined. This is nowhere=
 near removing the floor. Of course, if you can show me a case where curree=
ntly valid code changes behaviour, that's an entirely different thing.<div>=
<br></div><div>My motivation was that I don't want to see improved features=
 get worse names than the inferior but older functionality. I would prefer =
to be able to state that I want to use the new feature instead of the old, =
using the logical name.</div><div><br></div><div>Even if you can show me th=
at the idea of a disambiguation rule such as the one I suggested doesn't wo=
rk I still think that a mechanism to achieve the end goal would be desirabl=
e. At this point I don't really know what would be best. One naive way woul=
d be to use a compiler pragma, but compared to a using directive that's ver=
y clumsy and error prone.<br><div><br>Den l=F6rdagen den 31:e augusti 2013 =
kl. 21:16:36 UTC+2 skrev Gabriel Dos Reis:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">Bengt Gustafsson &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"JzWlOeGmumoJ">bengt.gu...@beamways.com</a><wbr>&gt=
; writes:
<br>
<br>[...]
<br>
<br>| My suggested solution is:
<br>|=20
<br>| If two things with the same name are found select the name in the mos=
t nested
<br>| namespace if the two conflicting namespaces are nested in each other.
<br>
<br>For C++11 and beyond, I would like to see fundamental things such as
<br>name lookup rules enjoy stability. &nbsp;Waking up in the morning and r=
ealize
<br>that half of the floor is gone and the living room turned into a
<br>restroom is no fun.
<br>
<br>-- Gaby
<br></blockquote></div></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_67_32752966.1378038789386--

.

On Sat, Aug 31, 2013 at 8:35 AM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> As an aside: Could anyone explain to me why type_traits ended up as a
> multitude of single purpose structs in the first place. To me it would ha=
ve
> been more logical to have one type_traits template like this:
>
>
> template <typename T> struct type_traits {
>     typedef const T add_const;
>     static const bool is_const =3D ...;
> };

Why do you find it so? Is something wrong with things that have a
"single purpose"?

> type_traits<MyType>::is_const
>
> vs
>
> is_const<MyType>::type

These two are different things... Personally, I'm okay with
`is_const<MyType>()` or `is_const<MyType>::value` in the exceedingly
rare occasions where `is_const<MyType>()` doesn't cut it. I do a lot
of TMP, and most of the time I just write `is_const<MyType>` anyway,
so I consider this is not-a-problem. Note that *this is still in a
world without the C++14 aliases*.

When it comes to the type transformation traits,
`type_traits<MyType>::add_const` is horrible compared to
`is_const_t<MyType>`. The reason it is horrible is that you have to
write the dreaded typename disambiguator, which IMO makes the code
harder to read because it is essentially noise (humans don't need the
disambiguator because it is obvious from the name that `add_const`
makes a new type). The alias templates don't need the typename
disambiguator, and that's the primary reason for their existence. I
use my own set of type transformation aliases that share their names
with the non-type transformation ones except they are in PascalCase.

> I assume that now with template variables coming up there is a suggestion=
 in
> the wings aimong at removing the ::value of the boolean type traits too. =
I
> strongly suggest that removing the ::type and the ::value be done in the
> same language version upgrade, and that the same change is done for ALL
> instances of ::type and ::value constructs, regardless of what part of th=
e
> standard library they are used in.

There isn't, and there shouldn't be a suggestion to remove the ::type
or ::value bits **ever**. Those are still useful in a way that the
alias templates cannot be. They allow you to pass around
meta-computations in a lazy manner.

Mit freundlichen Gr=FC=DFen,

Martinho

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

.

Martinho Fernandes <martinho.fernandes@gmail.com> writes:

| There isn't, and there shouldn't be a suggestion to remove the ::type
| or ::value bits **ever**. Those are still useful in a way that the
| alias templates cannot be. They allow you to pass around
| meta-computations in a lazy manner.

This claim has always struck me as odd.  You can pass template aliases
as template argument, achieving the same purpose.  Resulting in a
cleaner syntax for the majority of uses.

-- Gaby

--

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

.

Bengt Gustafsson <bengt.gustafsson@beamways.com> writes:

[...]

| Even if you can show me that the idea of a disambiguation rule such as the one
| I suggested doesn't work I still think that a mechanism to achieve the end goal
| would be desirable.

Yes, the two are not necessarily related.

-- Gaby

--

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

.

On Sun, Sep 1, 2013 at 3:42 PM, Gabriel Dos Reis <gdr@axiomatics.org> wrote=
:
> Martinho Fernandes <martinho.fernandes@gmail.com> writes:
>
> | There isn't, and there shouldn't be a suggestion to remove the ::type
> | or ::value bits **ever**. Those are still useful in a way that the
> | alias templates cannot be. They allow you to pass around
> | meta-computations in a lazy manner.
>
> This claim has always struck me as odd.  You can pass template aliases
> as template argument, achieving the same purpose.  Resulting in a
> cleaner syntax for the majority of uses.

Here's an example. If you write `std::conditional_t<std::is_enum<T>(),
std::underlying_type_t<T>, T>`, that piece of code has undefined
behaviour (or maybe it is ill-formed; I'm not sure which, but both are
bad here), because it always evaluates the type
std::underlying_type<T>::type (underlying_type cannot be used on
non-enums). How would write this using only alias templates?

Mit freundlichen Gr=FC=DFen,

Martinho

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

.

Martinho Fernandes <martinho.fernandes@gmail.com> writes:

| On Sun, Sep 1, 2013 at 3:42 PM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
| > Martinho Fernandes <martinho.fernandes@gmail.com> writes:
| >
| > | There isn't, and there shouldn't be a suggestion to remove the ::type
| > | or ::value bits **ever**. Those are still useful in a way that the
| > | alias templates cannot be. They allow you to pass around
| > | meta-computations in a lazy manner.
| >
| > This claim has always struck me as odd.  You can pass template aliases
| > as template argument, achieving the same purpose.  Resulting in a
| > cleaner syntax for the majority of uses.
|
| Here's an example. If you write `std::conditional_t<std::is_enum<T>(),
| std::underlying_type_t<T>, T>`, that piece of code has undefined
| behaviour (or maybe it is ill-formed; I'm not sure which, but both are
| bad here), because it always evaluates the type
| std::underlying_type<T>::type (underlying_type cannot be used on
| non-enums). How would write this using only alias templates?

I am sorry, I do not understand your claim.  Are you asking to reproduce
an undefined behavior, or how to reproduce an "ill-formed" program fragment?


-- Gaby

--

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

.

------=_Part_254_20630628.1378076257217
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Den s=F6ndagen den 1:e september 2013 kl. 15:27:52 UTC+2 skrev R. Martinho=
=20
Fernandes:
>
> On Sat, Aug 31, 2013 at 8:35 AM, Bengt Gustafsson=20
> <bengt.gu...@beamways.com <javascript:>> wrote:=20
> > As an aside: Could anyone explain to me why type_traits ended up as a=
=20
> > multitude of single purpose structs in the first place. To me it would=
=20
> have=20
> > been more logical to have one type_traits template like this:=20
> >=20
> >=20
> > template <typename T> struct type_traits {=20
> >     typedef const T add_const;=20
> >     static const bool is_const =3D ...;=20
> > };=20
>
> Why do you find it so? Is something wrong with things that have a=20
> "single purpose"?=20
>
Namespace pollution.=20

>
> > type_traits<MyType>::is_const=20
> >=20
> > vs=20
> >=20
> > is_const<MyType>::type=20
>
> These two are different things... Personally, I'm okay with=20
> `is_const<MyType>()` or `is_const<MyType>::value` in the exceedingly=20
> rare occasions where `is_const<MyType>()` doesn't cut it. I do a lot=20
> of TMP, and most of the time I just write `is_const<MyType>` anyway,=20
> so I consider this is not-a-problem. Note that *this is still in a=20
> world without the C++14 aliases*.
>
Are you referring to variable templates here (which would get rid of the=20
trailing() needed for constexpr function implementation?). Either way I=20
don't understand your point, aren't we discussing new C++14 features here?=
=20
If so they should be able to use other C++14 features.
=20

>
> When it comes to the type transformation traits,=20
> `type_traits<MyType>::add_const` is horrible compared to=20
> `is_const_t<MyType>`. The reason it is horrible is that you have to=20
> write the dreaded typename disambiguator, which IMO makes the code=20
> harder to read because it is essentially noise (humans don't need the=20
> disambiguator because it is obvious from the name that `add_const`=20
> makes a new type). The alias templates don't need the typename=20
> disambiguator, and that's the primary reason for their existence. I=20
> use my own set of type transformation aliases that share their names=20
> with the non-type transformation ones except they are in PascalCase.
>
I think that _t is still better than having the same name in different case=
=20
versions. Adding PascalCase stuff in namespace std:: would break lots of=20
code for everyone that does a using namespace std and, like you, have done=
=20
their own things like AddConst.

Also, please enlighten me on why we have to write those tedious typename=20
disambiguators in the cases where the name IS known. In this case you can't=
=20
compile your code without the <type_traits> include which shows the=20
compiler that add_const::type is indeed a type and not a variable or=20
function. Yes, it is concievable that a specialization of add_const for=20
some type would have type being an int, but isn't it enough to check the=20
unspecialized class template and handle the fringe cases when instantiating=
=20
the template for that T?
=20

>
> > I assume that now with template variables coming up there is a=20
> suggestion in=20
> > the wings aimong at removing the ::value of the boolean type traits too=
..=20
> I=20
> > strongly suggest that removing the ::type and the ::value be done in th=
e=20
> > same language version upgrade, and that the same change is done for ALL=
=20
> > instances of ::type and ::value constructs, regardless of what part of=
=20
> the=20
> > standard library they are used in.=20
>
> There isn't, and there shouldn't be a suggestion to remove the ::type=20
> or ::value bits **ever**. Those are still useful in a way that the=20
> alias templates cannot be. They allow you to pass around=20
> meta-computations in a lazy manner.=20
>
I think that the convenience should be optimized for the common cases.=20
Passing things like add_const as a template template parameter would surely=
=20
be very much more uncommon than other uses. And this is especially true for=
=20
the predicates which will be much more heavily used with Constraints in the=
=20
picture.

And I am not saying that these older versions are to go away, I was=20
specifically calling for a mechanism to select which ones to use. Your=20
example shows that my "most nested namespace wins" rule should be augmented=
=20
with an clause that says that when you explicitly state the name of the=20
outer namespace you really mean it. Like this:

using namespace std;     // This codebase has elected to use std

using namespace std::type_traits_v2;    // This codebase _normally_ uses=20
the new type traits

bool x =3D is_const<T>;      // Here the new version is selected as there i=
s=20
no explicit qualification

template_meta_program<std::is_const> ...       // Here, as we are sending=
=20
is_const as a template template parameter we have to use the current=20
version in std, and so we have to qualify despite the using std above.

Note that we are not breaking any code here. If you don't want to use the=
=20
new type trats you don't have to. Only if you want to use them, but still=
=20
needs the template template parameter use case do you have to really sift=
=20
through your code and add std:: where the compiler tells you to.

If you are NOT using std today the line "using namespace=20
std::type_traits_v2;" will select new type_traits, but place them on the=20
global level, which is not what we want (we want them to appear as being in=
=20
the std namespace). Darned, it doesn't work for this case, does it? A=20
namespace alias like in "namespace std =3D std::type_traits_v2;" does not=
=20
work as (at least in VS2012) due to the fact that the lhs name must be=20
unknown in the current scope and std is already the name of another=20
namespace. I think it is arguable that allowing this would be logical as=20
namespaces are open, but it would require yet another language change,=20
albeit also benign as it only makes ill formed programs well defined. And=
=20
even if this construct could be made to work it would not be very obvious=
=20
what it does. Being able to sub-use for instance std::rel_ops as if they=20
were in std would however be a somewhat useful feature in general [although=
=20
the example is really bad, as it contains only operators. But what other=20
namespaces nested in std are there today?].

One idea which would both make the declaration more understandable and the=
=20
feature less risky would be to explicitly say that things are being added=
=20
to std:

namespace std +=3D std::type_traits_v2;

Well, not much of an improvement, is it?


--=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_254_20630628.1378076257217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den s=F6ndagen den 1:e september 2013 kl. 15:27:52=
 UTC+2 skrev R. Martinho Fernandes:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Sat, Aug 31, 2013 at 8:35 AM, Bengt Gustafsson
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
XfMJv_Hrt64J">bengt.gu...@beamways.com</a><wbr>&gt; wrote:
<br>&gt; As an aside: Could anyone explain to me why type_traits ended up a=
s a
<br>&gt; multitude of single purpose structs in the first place. To me it w=
ould have
<br>&gt; been more logical to have one type_traits template like this:
<br>&gt;
<br>&gt;
<br>&gt; template &lt;typename T&gt; struct type_traits {
<br>&gt; &nbsp; &nbsp; typedef const T add_const;
<br>&gt; &nbsp; &nbsp; static const bool is_const =3D ...;
<br>&gt; };
<br>
<br>Why do you find it so? Is something wrong with things that have a
<br>"single purpose"?
<br></blockquote><div>Namespace pollution.&nbsp;</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">
<br>&gt; type_traits&lt;MyType&gt;::is_const
<br>&gt;
<br>&gt; vs
<br>&gt;
<br>&gt; is_const&lt;MyType&gt;::type
<br>
<br>These two are different things... Personally, I'm okay with
<br>`is_const&lt;MyType&gt;()` or `is_const&lt;MyType&gt;::value` in the ex=
ceedingly
<br>rare occasions where `is_const&lt;MyType&gt;()` doesn't cut it. I do a =
lot
<br>of TMP, and most of the time I just write `is_const&lt;MyType&gt;` anyw=
ay,
<br>so I consider this is not-a-problem. Note that *this is still in a
<br>world without the C++14 aliases*.<br></blockquote><div>Are you referrin=
g to variable templates here (which would get rid of the trailing() needed =
for constexpr function implementation?). Either way I don't understand your=
 point, aren't we discussing new C++14 features here? If so they should be =
able to use other C++14 features.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>When it comes to the type transformation traits,
<br>`type_traits&lt;MyType&gt;::add_<wbr>const` is horrible compared to
<br>`is_const_t&lt;MyType&gt;`. The reason it is horrible is that you have =
to
<br>write the dreaded typename disambiguator, which IMO makes the code
<br>harder to read because it is essentially noise (humans don't need the
<br>disambiguator because it is obvious from the name that `add_const`
<br>makes a new type). The alias templates don't need the typename
<br>disambiguator, and that's the primary reason for their existence. I
<br>use my own set of type transformation aliases that share their names
<br>with the non-type transformation ones except they are in PascalCase.<br=
></blockquote><div>I think that _t is still better than having the same nam=
e in different case versions. Adding PascalCase stuff in namespace std:: wo=
uld break lots of code for everyone that does a using namespace std and, li=
ke you, have done their own things like AddConst.</div><div><br></div><div>=
Also, please enlighten me on why we have to write those tedious typename di=
sambiguators in the cases where the name IS known. In this case you can't c=
ompile your code without the &lt;type_traits&gt; include which shows the co=
mpiler that add_const::type is indeed a type and not a variable or function=
.. Yes, it is concievable that a specialization of add_const for some type w=
ould have type being an int, but isn't it enough to check the unspecialized=
 class template and handle the fringe cases when instantiating the template=
 for that T?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>&gt; I assume that now with template variables coming up there is a sug=
gestion in
<br>&gt; the wings aimong at removing the ::value of the boolean type trait=
s too. I
<br>&gt; strongly suggest that removing the ::type and the ::value be done =
in the
<br>&gt; same language version upgrade, and that the same change is done fo=
r ALL
<br>&gt; instances of ::type and ::value constructs, regardless of what par=
t of the
<br>&gt; standard library they are used in.
<br>
<br>There isn't, and there shouldn't be a suggestion to remove the ::type
<br>or ::value bits **ever**. Those are still useful in a way that the
<br>alias templates cannot be. They allow you to pass around
<br>meta-computations in a lazy manner.
<br></blockquote><div>I think that the convenience should be optimized for =
the common cases. Passing things like add_const as a template template para=
meter would surely be very much more uncommon than other uses. And this is =
especially true for the predicates which will be much more heavily used wit=
h Constraints in the picture.</div><div><br></div><div>And I am not saying =
that these older versions are to go away, I was specifically calling for a =
mechanism to select which ones to use. Your example shows that my "most nes=
ted namespace wins" rule should be augmented with an clause that says that =
when you explicitly state the name of the outer namespace you really mean i=
t. Like this:</div><div><br></div><div>using namespace std; &nbsp; &nbsp; /=
/ This codebase has elected to use std</div><div><br></div><div>using names=
pace std::type_traits_v2; &nbsp; &nbsp;// This codebase _normally_ uses the=
 new type traits</div><div><br></div><div>bool x =3D is_const&lt;T&gt;; &nb=
sp; &nbsp; &nbsp;// Here the new version is selected as there is no explici=
t qualification</div><div><br></div><div>template_meta_program&lt;std::is_c=
onst&gt; ... &nbsp; &nbsp; &nbsp; // Here, as we are sending is_const as a =
template template parameter we have to use the current version in std, and =
so we have to qualify despite the using std above.</div><div><br></div><div=
>Note that we are not breaking any code here. If you don't want to use the =
new type trats you don't have to. Only if you want to use them, but still n=
eeds the template template parameter use case do you have to really sift th=
rough your code and add std:: where the compiler tells you to.</div><div><b=
r></div><div>If you are NOT using std today the line "<span style=3D"font-s=
ize: 13px;">using namespace std::type_traits_v2;" will select new type_trai=
ts, but place them on the global level, which is not what we want (we want =
them to appear as being in the std namespace). Darned, it doesn't work for =
this case, does it? A namespace alias like in "namespace std =3D std::type_=
traits_v2;" does not work as (at least in VS2012) due to the fact that the =
lhs name must be unknown in the current scope and std is already the name o=
f another namespace. I think it is arguable that allowing this would be log=
ical as namespaces are open, but it would require yet another language chan=
ge, albeit also benign as it only makes ill formed programs well defined. A=
nd even if this construct could be made to work it would not be very obviou=
s what it does. Being able to sub-use for instance std::rel_ops as if they =
were in std would however be a somewhat useful feature in general [although=
 the example is really bad, as it contains only operators. But what other n=
amespaces nested in std are there today?].</span></div><div><span style=3D"=
font-size: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">On=
e idea which would both make the declaration more understandable and the fe=
ature less risky would be to explicitly say that things are being added to =
std:</span></div><div><span style=3D"font-size: 13px;"><br></span></div><di=
v><span style=3D"font-size: 13px;">namespace std +=3D std::type_traits_v2;<=
/span></div><div><span style=3D"font-size: 13px;"><br></span></div><div><sp=
an style=3D"font-size: 13px;">Well, not much of an improvement, is it?</spa=
n></div><div><span style=3D"font-size: 13px;"><br></span></div><div><span s=
tyle=3D"font-size: 13px;"><br></span></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_254_20630628.1378076257217--

.

Oh gosh, so much confusion.

On Mon, Sep 2, 2013 at 12:57 AM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
>> Why do you find it so? Is something wrong with things that have a
>> "single purpose"?
>
> Namespace pollution.

That's something wrong with polluting namespaces, not with things that
have a single purpose. You could simply pack away all the still single
purpose things in a nested namespace, and voil=E0, no pollution, but
still single purpose structs.

>> These two are different things... Personally, I'm okay with
>> `is_const<MyType>()` or `is_const<MyType>::value` in the exceedingly
>> rare occasions where `is_const<MyType>()` doesn't cut it. I do a lot
>> of TMP, and most of the time I just write `is_const<MyType>` anyway,
>> so I consider this is not-a-problem. Note that *this is still in a
>> world without the C++14 aliases*.
>
> Are you referring to variable templates here (which would get rid of the
> trailing() needed for constexpr function implementation?). Either way I
> don't understand your point, aren't we discussing new C++14 features here=
?
> If so they should be able to use other C++14 features.

No, I am not referring to variable templates. I am referring to
passing `is_const<MyType>` as a type.

>> When it comes to the type transformation traits,
>> `type_traits<MyType>::add_const` is horrible compared to
>> `is_const_t<MyType>`. The reason it is horrible is that you have to
>> write the dreaded typename disambiguator, which IMO makes the code
>> harder to read because it is essentially noise (humans don't need the
>> disambiguator because it is obvious from the name that `add_const`
>> makes a new type). The alias templates don't need the typename
>> disambiguator, and that's the primary reason for their existence. I
>> use my own set of type transformation aliases that share their names
>> with the non-type transformation ones except they are in PascalCase.
>
> I think that _t is still better than having the same name in different ca=
se
> versions. Adding PascalCase stuff in namespace std:: would break lots of
> code for everyone that does a using namespace std and, like you, have don=
e
> their own things like AddConst.

That's kinda sorta irrelevant. People that use `using namespace std`
reap what they sow. Personally it never caused me trouble because I
don't use `using namespace std` and I don't make use of the global
namespace.

> Also, please enlighten me on why we have to write those tedious typename
> disambiguators in the cases where the name IS known.

type_traits<T>::add_const, where T is a template parameter, is a
dependent name. It's **exactly the same** reason add_const<T>::type
requires the disambiguator. They both have the form A<T>::C where T is
a template parameter and C is a nested type.

> In this case you can't
> compile your code without the <type_traits> include which shows the compi=
ler
> that add_const::type is indeed a type and not a variable or function.

No, the #include does not show anything like that to the compiler.
This Stack Overflow answer
http://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put-th=
e-template-and-typename-keywords/613132#613132
is recommended reading.

> Yes,
> it is concievable that a specialization of add_const for some type would
> have type being an int, but isn't it enough to check the unspecialized cl=
ass
> template and handle the fringe cases when instantiating the template for
> that T?

No, it is not. C++ just doesn't work this way (and it's messy enough as it =
is)

--=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_433_22040674.1378237170503
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Den tisdagen den 3:e september 2013 kl. 00:07:18 UTC+2 skrev R. Martinho=20
Fernandes:
>
> Oh gosh, so much confusion.=20
>
> On Mon, Sep 2, 2013 at 12:57 AM, Bengt Gustafsson=20
> <bengt.gu...@beamways.com <javascript:>> wrote:=20
> >> Why do you find it so? Is something wrong with things that have a=20
> >> "single purpose"?=20
> >=20
> > Namespace pollution.=20
>
> That's something wrong with polluting namespaces, not with things that=20
> have a single purpose. You could simply pack away all the still single=20
> purpose things in a nested namespace, and voil=E0, no pollution, but=20
> still single purpose structs.
>
=20
Of course you could tuck them away, but this was no done in the case of=20
type traits, was it?

What I was contemplating was if there was some definite advantage to the=20
design that was selected over the more straightforward imlementation. A=20
guess would be that it was due to the plethora of specializations that woul=
d
be needed to fill in the different member types and bools of a=20
type_traits<T> for different types of T, given that you didn't have the=20
different is_const and add_reference etc. already.

If we now view (just as for the _t named usings) the current class=20
templates as a base functionality, this problem with implementing a=20
type_traits template is non-existent. Going in the direction of a=20
type_traits class template would rid us of those _t suffixed that will be=
=20
really hard to explain in 10 years time. The resulting template could also=
=20
be the basis for CTTI, which would of course need that the compiler must=20
magically add for instance a special list of members for each=20
specialization of it. This could be done in a later language version.


> >> These two are different things... Personally, I'm okay with=20
> >> `is_const<MyType>()` or `is_const<MyType>::value` in the exceedingly=
=20
> >> rare occasions where `is_const<MyType>()` doesn't cut it. I do a lot=
=20
> >> of TMP, and most of the time I just write `is_const<MyType>` anyway,=
=20
> >> so I consider this is not-a-problem. Note that *this is still in a=20
> >> world without the C++14 aliases*.=20
> >=20
> > Are you referring to variable templates here (which would get rid of th=
e=20
> > trailing() needed for constexpr function implementation?). Either way I=
=20
> > don't understand your point, aren't we discussing new C++14 features=20
> here?=20
> > If so they should be able to use other C++14 features.=20
>
> No, I am not referring to variable templates. I am referring to=20
> passing `is_const<MyType>` as a type.
>
Ok, let's see, you are passing is_const<MyType> as a type to some template.=
=20
This template would have to know that the template parameter it gets has=20
only one member and that is ::value. Now there are around 10 dfferent class=
=20
templates that could be useful for passing like this. Sorry, but I still=20
don't understand your point. I re-read your text above several times but it=
=20
is too vauge, and also inconsistent in that you say that you=20
write `is_const<MyType>()` instead of `is_const<MyType>()`. Obviously you=
=20
are doing TMP in very different areas than I have. As is_const<T>::value is=
=20
static I don't see much of a point in instantiating is_const, and if you do=
=20
you are stepping out of the TMP realm anyway.

=20

>
> >> When it comes to the type transformation traits,=20
> >> `type_traits<MyType>::add_const` is horrible compared to=20
> >> `is_const_t<MyType>`. The reason it is horrible is that you have to=20
> >> write the dreaded typename disambiguator, which IMO makes the code=20
> >> harder to read because it is essentially noise (humans don't need the=
=20
> >> disambiguator because it is obvious from the name that `add_const`=20
> >> makes a new type). The alias templates don't need the typename=20
> >> disambiguator, and that's the primary reason for their existence. I=20
> >> use my own set of type transformation aliases that share their names=
=20
> >> with the non-type transformation ones except they are in PascalCase.=
=20
> >=20
> > I think that _t is still better than having the same name in different=
=20
> case=20
> > versions. Adding PascalCase stuff in namespace std:: would break lots o=
f=20
> > code for everyone that does a using namespace std and, like you, have=
=20
> done=20
> > their own things like AddConst.=20
>
> That's kinda sorta irrelevant. People that use `using namespace std`=20
> reap what they sow. Personally it never caused me trouble because I=20
> don't use `using namespace std` and I don't make use of the global=20
> namespace.
>
I hope that this type of arrogance is not too widespread in the C++=20
standards committee. I'm sure that there are lots of major code bases out=
=20
there which do using namespace std. I would say that as long as you stick t=
o
lower case names it is not so much of a problem but with the new names for=
=20
constraints, for instance std::Object such code bases will be very badly=20
hurt. It is not going to help C++ reputation if such severe breaking=20
changes are introduced, even if the users have transgressed a programming=
=20
rule. The problem is that the short term advantage of not having to write=
=20
std:: on all library names.=20

Also: I have been working over 10 years with a code base we started with in=
=20
1994. For several years the compilers we used didn't even have namespaces.=
=20
We had a third party STL which had a #define to disable namespaces where=20
the compilers didn't have them. When we got a compiler with namespaces we=
=20
already had over 500 000 lines worth of code using STL containers,=20
algorithms etc. The only practical solution to migrate to the new compiler=
=20
with namespaces and an STL in std was of course to add a "using namespace=
=20
std" in a header everyone includes. I'm sure that there are lots of code=20
bases like this out there.


> > Also, please enlighten me on why we have to write those tedious typenam=
e=20
> > disambiguators in the cases where the name IS known.=20
>
> type_traits<T>::add_const, where T is a template parameter, is a=20
> dependent name. It's **exactly the same** reason add_const<T>::type=20
> requires the disambiguator. They both have the form A<T>::C where T is=20
> a template parameter and C is a nested type.=20
>
> > In this case you can't=20
> > compile your code without the <type_traits> include which shows the=20
> compiler=20
> > that add_const::type is indeed a type and not a variable or function.=
=20
>
> No, the #include does not show anything like that to the compiler.=20
> This Stack Overflow answer=20
>
> http://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put-=
the-template-and-typename-keywords/613132#613132=20
> is recommended reading.=20
>
> I'm of course fully aware of the basics of disambiguiation and why it is=
=20
needed. The problem is that I find that at least VS2012 requires it even=20
when it knows full well that it is a type.

You claim that for type_traits<MyType>::add_const a 'typename' would be=20
required, in places where it would not for add_const<MyType>::type. This=20
makes no sense at all to me. The constructs are totally similar, a typedef=
=20
inside a known class template instantiated for a (potentially) unknown type=
..

And yes, at least in VS2012 you need the 'typename' for both cases if=20
MyType is a template parameter but not if it is a concrete type.

In this case, except for odd cases where a specialization replaces a type=
=20
in the base implementation with a value in the specialization the compiler=
=20
would have no problem deducing that type in add_const<MyType>::type
is a type. That's written in the add_const class head. You don't have to=20
see the MyType class head to know this, and of course you won't as when=20
parsing it is just a T.

Thus my original question was perfectly valid.

I did a very un-scientific scan for typename disambiguation cases in a=20
small code base I have. It contained around 60 places where I had had to=20
write 'typename' to disambiguate. Interestingly ALL of them were of the=20
form: known_template<template-parameter>::type, about half of them=20
enable_if and half the different remove_const, decay etc.
=20

> > Yes,=20
> > it is concievable that a specialization of add_const for some type woul=
d=20
> > have type being an int, but isn't it enough to check the unspecialized=
=20
> class=20
> > template and handle the fringe cases when instantiating the template fo=
r=20
> > that T?=20
>
> No, it is not. C++ just doesn't work this way (and it's messy enough as i=
t=20
> is)
>
=20
"C++ just doesn't work that way" is a really bad answer in a group with the=
=20
purpose of discussing changes and improvements to the language.

--=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_433_22040674.1378237170503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den tisdagen den 3:e september 2013 kl. 00:07:18 U=
TC+2 skrev R. Martinho Fernandes:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">Oh gosh, so much confusion.
<br>
<br>On Mon, Sep 2, 2013 at 12:57 AM, Bengt Gustafsson
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
iMuAkPeN-xYJ">bengt.gu...@beamways.com</a><wbr>&gt; wrote:
<br>&gt;&gt; Why do you find it so? Is something wrong with things that hav=
e a
<br>&gt;&gt; "single purpose"?
<br>&gt;
<br>&gt; Namespace pollution.
<br>
<br>That's something wrong with polluting namespaces, not with things that
<br>have a single purpose. You could simply pack away all the still single
<br>purpose things in a nested namespace, and voil=E0, no pollution, but
<br>still single purpose structs.<br></blockquote><div>&nbsp;</div><div>Of =
course you could tuck them away, but this was no done in the case of type t=
raits, was it?</div><div><br></div><div>What I was contemplating was if the=
re was some definite advantage to the design that was selected over the mor=
e straightforward imlementation. A guess would be that it was due to the pl=
ethora of specializations that would</div><div>be needed to fill in the dif=
ferent member types and bools of a type_traits&lt;T&gt; for different types=
 of T, given that you didn't have the different is_const and add_reference =
etc. already.</div><div><br></div><div>If we now view (just as for the _t n=
amed usings) the current class templates as a base functionality, this prob=
lem with implementing a type_traits template is non-existent. Going in the =
direction of a type_traits class template would rid us of those _t suffixed=
 that will be really hard to explain in 10 years time. The resulting templa=
te could also be the basis for CTTI, which would of course need that the co=
mpiler must magically add for instance a special list of members for each s=
pecialization of it. This could be done in a later language version.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;&gt; These two are different things... Personally, I'm okay with
<br>&gt;&gt; `is_const&lt;MyType&gt;()` or `is_const&lt;MyType&gt;::value` =
in the exceedingly
<br>&gt;&gt; rare occasions where `is_const&lt;MyType&gt;()` doesn't cut it=
.. I do a lot
<br>&gt;&gt; of TMP, and most of the time I just write `is_const&lt;MyType&=
gt;` anyway,
<br>&gt;&gt; so I consider this is not-a-problem. Note that *this is still =
in a
<br>&gt;&gt; world without the C++14 aliases*.
<br>&gt;
<br>&gt; Are you referring to variable templates here (which would get rid =
of the
<br>&gt; trailing() needed for constexpr function implementation?). Either =
way I
<br>&gt; don't understand your point, aren't we discussing new C++14 featur=
es here?
<br>&gt; If so they should be able to use other C++14 features.
<br>
<br>No, I am not referring to variable templates. I am referring to
<br>passing `is_const&lt;MyType&gt;` as a type.<br></blockquote><div>Ok, le=
t's see, you are passing is_const&lt;MyType&gt; as a type to some template.=
 This template would have to know that the template parameter it gets has o=
nly one member and that is ::value. Now there are around 10 dfferent class =
templates that could be useful for passing like this. Sorry, but I still do=
n't understand your point. I re-read your text above several times but it i=
s too vauge, and also inconsistent in that you say that you write&nbsp;`is_=
const&lt;MyType&gt;()`&nbsp;instead of&nbsp;`is_const&lt;MyType&gt;()`. Obv=
iously you are doing TMP in very different areas than I have. As is_const&l=
t;T&gt;::value is static I don't see much of a point in instantiating is_co=
nst, and if you do you are stepping out of the TMP realm anyway.</div><div>=
<br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt;&gt; When it comes to the type transformation traits,
<br>&gt;&gt; `type_traits&lt;MyType&gt;::add_<wbr>const` is horrible compar=
ed to
<br>&gt;&gt; `is_const_t&lt;MyType&gt;`. The reason it is horrible is that =
you have to
<br>&gt;&gt; write the dreaded typename disambiguator, which IMO makes the =
code
<br>&gt;&gt; harder to read because it is essentially noise (humans don't n=
eed the
<br>&gt;&gt; disambiguator because it is obvious from the name that `add_co=
nst`
<br>&gt;&gt; makes a new type). The alias templates don't need the typename
<br>&gt;&gt; disambiguator, and that's the primary reason for their existen=
ce. I
<br>&gt;&gt; use my own set of type transformation aliases that share their=
 names
<br>&gt;&gt; with the non-type transformation ones except they are in Pasca=
lCase.
<br>&gt;
<br>&gt; I think that _t is still better than having the same name in diffe=
rent case
<br>&gt; versions. Adding PascalCase stuff in namespace std:: would break l=
ots of
<br>&gt; code for everyone that does a using namespace std and, like you, h=
ave done
<br>&gt; their own things like AddConst.
<br>
<br>That's kinda sorta irrelevant. People that use `using namespace std`
<br>reap what they sow. Personally it never caused me trouble because I
<br>don't use `using namespace std` and I don't make use of the global
<br>namespace.<br></blockquote><div>I hope that this type of arrogance is n=
ot too widespread in the C++ standards committee. I'm sure that there are l=
ots of major code bases out there which do using namespace std. I would say=
 that as long as you stick to</div><div>lower case names it is not so much =
of a problem but with the new names for constraints, for instance std::Obje=
ct such code bases will be very badly hurt. It is not going to help C++ rep=
utation if such severe breaking changes are introduced, even if the users h=
ave transgressed a programming rule. The problem is that the short term adv=
antage of not having to write std:: on all library names.&nbsp;</div><div><=
br></div><div>Also: I have been working over 10 years with a code base we s=
tarted with in 1994. For several years the compilers we used didn't even ha=
ve namespaces. We had a third party STL which had a #define to disable name=
spaces where the compilers didn't have them. When we got a compiler with na=
mespaces we already had over 500 000 lines worth of code using STL containe=
rs, algorithms etc. The only practical solution to migrate to the new compi=
ler with namespaces and an STL in std was of course to add a "using namespa=
ce std" in a header everyone includes. I'm sure that there are lots of code=
 bases like this out there.</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
<br>&gt; Also, please enlighten me on why we have to write those tedious ty=
pename
<br>&gt; disambiguators in the cases where the name IS known.
<br>
<br>type_traits&lt;T&gt;::add_const, where T is a template parameter, is a
<br>dependent name. It's **exactly the same** reason add_const&lt;T&gt;::ty=
pe
<br>requires the disambiguator. They both have the form A&lt;T&gt;::C where=
 T is
<br>a template parameter and C is a nested type.
<br>
<br>&gt; In this case you can't
<br>&gt; compile your code without the &lt;type_traits&gt; include which sh=
ows the compiler
<br>&gt; that add_const::type is indeed a type and not a variable or functi=
on.
<br>
<br>No, the #include does not show anything like that to the compiler.
<br>This Stack Overflow answer
<br><a href=3D"http://stackoverflow.com/questions/610245/where-and-why-do-i=
-have-to-put-the-template-and-typename-keywords/613132#613132" target=3D"_b=
lank">http://stackoverflow.com/<wbr>questions/610245/where-and-<wbr>why-do-=
i-have-to-put-the-<wbr>template-and-typename-<wbr>keywords/613132#613132</a=
>
<br>is recommended reading.
<br>
<br></blockquote><div>I'm of course fully aware of the basics of disambigui=
ation and why it is needed. The problem is that I find that at least VS2012=
 requires it even when it knows full well that it is a type.</div><div><br>=
</div><div>You claim that for type_traits&lt;MyType&gt;::add_const a 'typen=
ame' would be required, in places where it would not for add_const&lt;MyTyp=
e&gt;::type. This makes no sense at all to me. The constructs are totally s=
imilar, a typedef inside a known class template instantiated for a (potenti=
ally) unknown type.</div><div><br></div><div>And yes, at least in VS2012 yo=
u need the 'typename' for both cases if MyType is a template parameter but =
not if it is a concrete type.</div><div><br></div><div>In this case, except=
 for odd cases where a specialization replaces a type in the base implement=
ation with a value in the specialization the compiler would have no problem=
 deducing that type in&nbsp;<span style=3D"font-size: 13px;">add_const&lt;M=
yType&gt;::type</span></div><div><span style=3D"font-size: 13px;">is a type=
.. That's written in the add_const class head. You don't have to see the MyT=
ype class head to know this, and of course you won't as when parsing it is =
just a T.</span></div><div><span style=3D"font-size: 13px;"><br></span></di=
v><div>Thus my original question was perfectly valid.</div><div><br></div><=
div>I did a very un-scientific scan for typename disambiguation cases in a =
small code base I have. It contained around 60 places where I had had to wr=
ite 'typename' to disambiguate. Interestingly ALL of them were of the form:=
 known_template&lt;template-parameter&gt;::type, about half of them enable_=
if and half the different remove_const, decay etc.</div><div>&nbsp;</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">&gt; Yes,
<br>&gt; it is concievable that a specialization of add_const for some type=
 would
<br>&gt; have type being an int, but isn't it enough to check the unspecial=
ized class
<br>&gt; template and handle the fringe cases when instantiating the templa=
te for
<br>&gt; that T?
<br>
<br>No, it is not. C++ just doesn't work this way (and it's messy enough as=
 it is)<br></blockquote><div>&nbsp;</div><div>"C++ just doesn't work that w=
ay" is a really bad answer in a group with the purpose of discussing change=
s and improvements to the language.</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_433_22040674.1378237170503--

.

------=_Part_612_30098588.1378245575356
Content-Type: text/plain; charset=ISO-8859-1


>
> I hope that this type of arrogance is not too widespread in the C++
> standards committee.


It absolutely is. This is exactly what you get when you using namespace std; you
get name clashes with all future names added to std. If you don't like it,
don't use namespace std. In fact, I can tell you that I attended Bristol
and was in a LEWG meeting where this issue was raised, and my memory of
that event is that we decided to not care whatsoever.

"C++ just doesn't work that way" is a really bad answer in a group with the
> purpose of discussing changes and improvements to the language.


You're not talking about some detail or obscure corner. Changing this fact
would require re-engineering a LOT of the language. That's way more than
can be achieved today.

--

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

------=_Part_612_30098588.1378245575356
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><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;">I hope that this type of arro=
gance is not too widespread in the C++ standards committee. </blockquote><d=
iv>&nbsp;</div>It absolutely is. This is exactly what you get when you&nbsp=
;<span class=3D"styled-by-prettify" style=3D"background-color: rgb(250, 250=
, 250); color: rgb(0, 0, 136);">using</span><span class=3D"styled-by-pretti=
fy" style=3D"background-color: rgb(250, 250, 250); color: rgb(0, 0, 0);"> <=
/span><span class=3D"styled-by-prettify" style=3D"background-color: rgb(250=
, 250, 250); color: rgb(0, 0, 136);">namespace</span><span class=3D"styled-=
by-prettify" style=3D"background-color: rgb(250, 250, 250); color: rgb(0, 0=
, 0);"> std</span><span class=3D"styled-by-prettify" style=3D"background-co=
lor: rgb(250, 250, 250); color: rgb(102, 102, 0);">;</span>&nbsp;you get na=
me clashes with all future names added to std. If you don't like it, don't =
use namespace std. In fact, I can tell you that I attended Bristol and was =
in a LEWG meeting where this issue was raised, and my memory of that event =
is that we decided to not care whatsoever.<div><br></div><div><blockquote c=
lass=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; padd=
ing-left: 1ex;">"C++ just doesn't work that way" is a really bad answer in =
a group with the purpose of discussing changes and improvements to the lang=
uage.</blockquote><div><br></div><div>You're not talking about some detail =
or obscure corner. Changing this fact would require re-engineering a LOT of=
 the language. That's way more than can be achieved today.&nbsp;</div><div>=
</div></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_612_30098588.1378245575356--

.

--047d7b62249afa2e7b04e5822be1
Content-Type: text/plain; charset=ISO-8859-1

On 3 September 2013 14:39, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

> Also: I have been working over 10 years with a code base we started with
> in 1994. For several years the compilers we used didn't even have
> namespaces. We had a third party STL which had a #define to disable
> namespaces where the compilers didn't have them. When we got a compiler
> with namespaces we already had over 500 000 lines worth of code using STL
> containers, algorithms etc. The only practical solution to migrate to the
> new compiler with namespaces and an STL in std was of course to add a
> "using namespace std" in a header everyone includes.
>

You are saying that the only practical solution was to adopt what was, even
in 2004, widely known to be an extremely poor practice <
http://www.drdobbs.com/using-me/184401782>?

You had another choice, but you chose to do an expedient hack.  IMO, while
the committee isn't going to deliberately break your code base, the
committee isn't going to spend any effort protecting your code base in this
instance, either.  If it were my responsibility, I'd bite the bullet and
fix it right, sooner rather than later (and in previous jobs it has been
and I did).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

--047d7b62249afa2e7b04e5822be1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 3 September 2013 14:39, Bengt Gustafsson <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">=
bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"gmail_=
extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">Also: I have been working over 10 years with a code base=
 we started with in 1994. For several years the compilers we used didn&#39;=
t even have namespaces. We had a third party STL which had a #define to dis=
able namespaces where the compilers didn&#39;t have them. When we got a com=
piler with namespaces we already had over 500 000 lines worth of code using=
 STL containers, algorithms etc. The only practical solution to migrate to =
the new compiler with namespaces and an STL in std was of course to add a &=
quot;using namespace std&quot; in a header everyone includes. </div>

</blockquote><div><br></div><div>You are saying that the only practical sol=
ution was to adopt what was, even in 2004, widely known to be an extremely =
poor practice &lt;<a href=3D"http://www.drdobbs.com/using-me/184401782">htt=
p://www.drdobbs.com/using-me/184401782</a>&gt;?<br>

<br></div><div>You had another choice, but you chose to do an expedient hac=
k.=A0 IMO, while the committee isn&#39;t going to deliberately break your c=
ode base, the committee isn&#39;t going to spend any effort protecting your=
 code base in this instance, either.=A0 If it were my responsibility, I&#39=
;d bite the bullet and fix it right, sooner rather than later (and in previ=
ous jobs it has been and I did).<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</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 />

--047d7b62249afa2e7b04e5822be1--

.

--001a1133158ee5373104e5826a06
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 3, 2013 at 3:25 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 3 September 2013 14:39, Bengt Gustafsson <bengt.gustafsson@beamways.com
> > wrote:
>
>> Also: I have been working over 10 years with a code base we started with
>> in 1994. For several years the compilers we used didn't even have
>> namespaces. We had a third party STL which had a #define to disable
>> namespaces where the compilers didn't have them. When we got a compiler
>> with namespaces we already had over 500 000 lines worth of code using STL
>> containers, algorithms etc. The only practical solution to migrate to the
>> new compiler with namespaces and an STL in std was of course to add a
>> "using namespace std" in a header everyone includes.
>>
>
> You are saying that the only practical solution was to adopt what was,
> even in 2004, widely known to be an extremely poor practice <
> http://www.drdobbs.com/using-me/184401782>?
>
> You had another choice, but you chose to do an expedient hack.  IMO, while
> the committee isn't going to deliberately break your code base, the
> committee isn't going to spend any effort protecting your code base in this
> instance, either.  If it were my responsibility, I'd bite the bullet and
> fix it right, sooner rather than later (and in previous jobs it has been
> and I did).
>

These days, this is not even a particularly big bullet to bite.

The Clang project would certainly accept a tool to replace a
using-directive with explicit qualification or per-source-file
using-declarations (maybe as part of the C++11 migrator, soon to be renamed
clang-modernize). Such a tool should be pretty simple to write, and much
easier than manually fixing a 0.5 MLoC codebase. Some documentation here:

http://clang.llvm.org/docs/LibTooling.html
http://clang.llvm.org/extra/cpp11-migrate.html
http://llvm.org/docs/DeveloperPolicy.html
http://llvm.org/docs/CodingStandards.html

--

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

--001a1133158ee5373104e5826a06
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Tue, Sep 3, 2013 at 3:25 PM, Nevin Liber <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">ne=
vin@eviloverlord.com</a>&gt;</span> wrote:<br></div><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">
<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"im">On 3 September 2013 14:=
39, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafss=
on@beamways.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</s=
pan> wrote:<br>
</div><div class=3D"gmail_extra">

<div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr">Also: I have been working over 10 years with a code base we started wit=
h in 1994. For several years the compilers we used didn&#39;t even have nam=
espaces. We had a third party STL which had a #define to disable namespaces=
 where the compilers didn&#39;t have them. When we got a compiler with name=
spaces we already had over 500 000 lines worth of code using STL containers=
, algorithms etc. The only practical solution to migrate to the new compile=
r with namespaces and an STL in std was of course to add a &quot;using name=
space std&quot; in a header everyone includes. </div>


</blockquote><div><br></div></div><div>You are saying that the only practic=
al solution was to adopt what was, even in 2004, widely known to be an extr=
emely poor practice &lt;<a href=3D"http://www.drdobbs.com/using-me/18440178=
2" target=3D"_blank">http://www.drdobbs.com/using-me/184401782</a>&gt;?<br>


<br></div><div>You had another choice, but you chose to do an expedient hac=
k.=A0 IMO, while the committee isn&#39;t going to deliberately break your c=
ode base, the committee isn&#39;t going to spend any effort protecting your=
 code base in this instance, either.=A0 If it were my responsibility, I&#39=
;d bite the bullet and fix it right, sooner rather than later (and in previ=
ous jobs it has been and I did).</div>
</div></div></div></blockquote><div><br></div><div>These days, this is not =
even a particularly big bullet to bite.</div><div><br></div><div><div>The C=
lang project would certainly accept a tool to replace a using-directive wit=
h explicit qualification or per-source-file using-declarations (maybe as pa=
rt of the C++11 migrator, soon to be renamed clang-modernize). Such a tool =
should be pretty simple to write, and much easier than manually fixing a 0.=
5 MLoC codebase. Some documentation here:<br class=3D"">
<br></div><a href=3D"http://clang.llvm.org/docs/LibTooling.html">http://cla=
ng.llvm.org/docs/LibTooling.html</a><br><div><a href=3D"http://clang.llvm.o=
rg/extra/cpp11-migrate.html">http://clang.llvm.org/extra/cpp11-migrate.html=
</a></div>
</div><div><a href=3D"http://llvm.org/docs/DeveloperPolicy.html">http://llv=
m.org/docs/DeveloperPolicy.html</a><br></div><div><a href=3D"http://llvm.or=
g/docs/CodingStandards.html">http://llvm.org/docs/CodingStandards.html</a><=
/div>
</div></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 />

--001a1133158ee5373104e5826a06--

.

------=_Part_1115_4125293.1378252851062
Content-Type: text/plain; charset=ISO-8859-1

Well, finally something useful. If a tool like that migrator (which I
haven't checked out yet) had been available around 2000 when we got the
namespace-aware compiler (certainly way before 2004 anyway), we would
surely have used it. But biting such bullets was certainly not an option, I
am 100% sure that the reply from management would have been "stick with the
old compiler then" if I had suggested such an effort to be able to upgrade
the compiler.

Den onsdagen den 4:e september 2013 kl. 00:43:28 UTC+2 skrev Richard Smith:
>
> On Tue, Sep 3, 2013 at 3:25 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>
> > wrote:
>
>> On 3 September 2013 14:39, Bengt Gustafsson <bengt.gu...@beamways.com<javascript:>
>> > wrote:
>>
>>> Also: I have been working over 10 years with a code base we started with
>>> in 1994. For several years the compilers we used didn't even have
>>> namespaces. We had a third party STL which had a #define to disable
>>> namespaces where the compilers didn't have them. When we got a compiler
>>> with namespaces we already had over 500 000 lines worth of code using STL
>>> containers, algorithms etc. The only practical solution to migrate to the
>>> new compiler with namespaces and an STL in std was of course to add a
>>> "using namespace std" in a header everyone includes.
>>>
>>
>> You are saying that the only practical solution was to adopt what was,
>> even in 2004, widely known to be an extremely poor practice <
>> http://www.drdobbs.com/using-me/184401782>?
>>
>> You had another choice, but you chose to do an expedient hack.  IMO,
>> while the committee isn't going to deliberately break your code base, the
>> committee isn't going to spend any effort protecting your code base in this
>> instance, either.  If it were my responsibility, I'd bite the bullet and
>> fix it right, sooner rather than later (and in previous jobs it has been
>> and I did).
>>
>
> These days, this is not even a particularly big bullet to bite.
>
> The Clang project would certainly accept a tool to replace a
> using-directive with explicit qualification or per-source-file
> using-declarations (maybe as part of the C++11 migrator, soon to be renamed
> clang-modernize). Such a tool should be pretty simple to write, and much
> easier than manually fixing a 0.5 MLoC codebase. Some documentation here:
>
> http://clang.llvm.org/docs/LibTooling.html
> http://clang.llvm.org/extra/cpp11-migrate.html
> http://llvm.org/docs/DeveloperPolicy.html
> http://llvm.org/docs/CodingStandards.html
>

--

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

------=_Part_1115_4125293.1378252851062
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, finally something useful. If a tool like that migrat=
or (which I haven't checked out yet) had been available around 2000 when we=
 got the namespace-aware compiler (certainly way before 2004 anyway), we wo=
uld surely have used it. But biting such bullets was certainly not an optio=
n, I am 100% sure that the reply from management would have been "stick wit=
h the old compiler then" if I had suggested such an effort to be able to up=
grade the compiler.<br><br>Den onsdagen den 4:e september 2013 kl. 00:43:28=
 UTC+2 skrev Richard Smith:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>On Tue, Sep 3, 2013 at 3:25 PM, Nevin Liber <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"VG9CEOTwyGEJ">ne...@eviloverlord.com</a>&gt;</span> wrote:<br></div><di=
v><div class=3D"gmail_quote">
<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>On 3 September 2013 14:39, Bengt Gus=
tafsson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"VG9CEOTwyGEJ">bengt.gu...@beamways.com</a><wbr>&gt;</=
span> wrote:<br>
</div><div>

<div class=3D"gmail_quote"><div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Also: I h=
ave been working over 10 years with a code base we started with in 1994. Fo=
r several years the compilers we used didn't even have namespaces. We had a=
 third party STL which had a #define to disable namespaces where the compil=
ers didn't have them. When we got a compiler with namespaces we already had=
 over 500 000 lines worth of code using STL containers, algorithms etc. The=
 only practical solution to migrate to the new compiler with namespaces and=
 an STL in std was of course to add a "using namespace std" in a header eve=
ryone includes. </div>


</blockquote><div><br></div></div><div>You are saying that the only practic=
al solution was to adopt what was, even in 2004, widely known to be an extr=
emely poor practice &lt;<a href=3D"http://www.drdobbs.com/using-me/18440178=
2" target=3D"_blank">http://www.drdobbs.com/using-<wbr>me/184401782</a>&gt;=
?<br>


<br></div><div>You had another choice, but you chose to do an expedient hac=
k.&nbsp; IMO, while the committee isn't going to deliberately break your co=
de base, the committee isn't going to spend any effort protecting your code=
 base in this instance, either.&nbsp; If it were my responsibility, I'd bit=
e the bullet and fix it right, sooner rather than later (and in previous jo=
bs it has been and I did).</div>
</div></div></div></blockquote><div><br></div><div>These days, this is not =
even a particularly big bullet to bite.</div><div><br></div><div><div>The C=
lang project would certainly accept a tool to replace a using-directive wit=
h explicit qualification or per-source-file using-declarations (maybe as pa=
rt of the C++11 migrator, soon to be renamed clang-modernize). Such a tool =
should be pretty simple to write, and much easier than manually fixing a 0.=
5 MLoC codebase. Some documentation here:<br>
<br></div><a href=3D"http://clang.llvm.org/docs/LibTooling.html" target=3D"=
_blank">http://clang.llvm.org/docs/<wbr>LibTooling.html</a><br><div><a href=
=3D"http://clang.llvm.org/extra/cpp11-migrate.html" target=3D"_blank">http:=
//clang.llvm.org/extra/<wbr>cpp11-migrate.html</a></div>
</div><div><a href=3D"http://llvm.org/docs/DeveloperPolicy.html" target=3D"=
_blank">http://llvm.org/docs/<wbr>DeveloperPolicy.html</a><br></div><div><a=
 href=3D"http://llvm.org/docs/CodingStandards.html" target=3D"_blank">http:=
//llvm.org/docs/<wbr>CodingStandards.html</a></div>
</div></div></div>
</blockquote></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_1115_4125293.1378252851062--

.

On Tue, Sep 3, 2013 at 9:39 PM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
>> >> These two are different things... Personally, I'm okay with
>> >> `is_const<MyType>()` or `is_const<MyType>::value` in the exceedingly
>> >> rare occasions where `is_const<MyType>()` doesn't cut it. I do a lot
>> >> of TMP, and most of the time I just write `is_const<MyType>` anyway,
>> >> so I consider this is not-a-problem. Note that *this is still in a
>> >> world without the C++14 aliases*.
>> >
>> > Are you referring to variable templates here (which would get rid of t=
he
>> > trailing() needed for constexpr function implementation?). Either way =
I
>> > don't understand your point, aren't we discussing new C++14 features
>> > here?
>> > If so they should be able to use other C++14 features.
>>
>> No, I am not referring to variable templates. I am referring to
>> passing `is_const<MyType>` as a type.
>
> Ok, let's see, you are passing is_const<MyType> as a type to some templat=
e.
> This template would have to know that the template parameter it gets has
> only one member and that is ::value. Now there are around 10 dfferent cla=
ss
> templates that could be useful for passing like this. Sorry, but I still
> don't understand your point. I re-read your text above several times but =
it
> is too vauge, and also inconsistent in that you say that you write
> `is_const<MyType>()` instead of `is_const<MyType>()`. Obviously you are
> doing TMP in very different areas than I have. As is_const<T>::value is
> static I don't see much of a point in instantiating is_const, and if you =
do
> you are stepping out of the TMP realm anyway.

I don't say I write `is_const<MyType>()` instead of
`is_const<MyType>()`. You should probably re-read the text once more,
this time paying attention to the use of parentheses.

I said I don't have a problem with writing `is_const<MyType>()`
("Personally, I'm okay with
`is_const<MyType>()`"). However, `is_const<MyType>()` doesn't work in
all cases (because it relies on a conversion to bool, which doesn't
happen in all contexts). In those rare cases, I don't mind writing
``is_const<MyType>::value` instead ("or `is_const<MyType>::value` in
the exceedingly rare occasions where `is_const<MyType>()` doesn't cut
it."). Those cases are exceedingly rare because I pretty much never
actually want to use `is_const<MyType>()` ("I do a lot of TMP, and
most of the time I just write `is_const<MyType>` anyway). All my
metafunctions that need some bool parameter take a "meta-bool"
parameter instead (what the standard calls a UnaryTypeTrait with a
bool value), so I need neither parentheses nor ::value. It has the
added benefits of resulting in client code with less syntactic noise
(like `EnableIf<is_const<T>>`). It is also usable in templates that
take `template <typename...> class` template arguments, even if those
aren't great and there are better alternatives for higher-order
metafunctions (see Boost.Mpl).

>> type_traits<T>::add_const, where T is a template parameter, is a
>> dependent name. It's **exactly the same** reason add_const<T>::type
>> requires the disambiguator. They both have the form A<T>::C where T is
>> a template parameter and C is a nested type.
>>
>> > In this case you can't
>> > compile your code without the <type_traits> include which shows the
>> > compiler
>> > that add_const::type is indeed a type and not a variable or function.
>>
>> No, the #include does not show anything like that to the compiler.
>> This Stack Overflow answer
>>
>> http://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put=
-the-template-and-typename-keywords/613132#613132
>> is recommended reading.
>>
> I'm of course fully aware of the basics of disambiguiation and why it is
> needed. The problem is that I find that at least VS2012 requires it even
> when it knows full well that it is a type.

I feel like I am wasting my time on this. To prevent further waste, I
will be totally blunt: no, you are not fully aware of this issue. The
compiler doesn't know full well that it is a type until instantiation,
and MSVC is famous for not requiring typename when it should (because
it doesn't implement two-phase lookup), not the other way around. See
bug report closed as "Deferred":
https://connect.microsoft.com/VisualStudio/feedback/details/742478/support-=
two-phase-name-lookup.

> You claim that for type_traits<MyType>::add_const a 'typename' would be
> required, in places where it would not for add_const<MyType>::type. This
> makes no sense at all to me. The constructs are totally similar, a typede=
f
> inside a known class template instantiated for a (potentially) unknown ty=
pe.

I don't claim any of that, and this slander is the reason I am
bothering to write this reply at all. Right there in a part you quoted
from my reply (so you can't even claim to not have noticed it!) are
phrases like: "It's **exactly the same** reason add_const<T>::type
requires the disambiguator" and "They both have the form [X]". Notice
the use of the word "both" and the use of double asterisks around
"exactly the same" for emphasis. There is also a distinct lack of
words like "but" or "however" in that paragraph. How anyone can draw
the conclusion that I see the two as different? I have no idea, and
that's exactly why I am walking away from this fruitless discussion.

Mit freundlichen Gr=FC=DFen,

Martinho

--=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_5633_10524545.1378281980699
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ok, not to waste too much of youtr time, you were right, after about four=
=20
more re-reads I could decipher your text about the trailing () into=20
something logical. It was the or not being ment as being alternatives=20
between the two adjoining quoted examples but in a longer part of the=20
sentence that fooled me. Clearly I should expect a programming language=20
expert like you to be able to write prose exactly right, although I still=
=20
think the wording was a bit contrived.

And I made a fool of myself again on the second issue regarding the=20
typename. I was assuming that you were claiming this as a drawback for the=
=20
type_traits<T> solution as the argument "these two solutions have the same=
=20
disadvantage and therefore solution A is better" didn't seem to be a=20
rational argument. As far as I remember I wasn't claiming any reduction in=
=20
the use of 'typename' for my solution.

Of course, with the current language specification the Microsoft compiler=
=20
is too lenient on typename, and in contrast with its other shortcomings in=
=20
this area it does not show up as an error message at the time of actual=20
instantiation as by that time all the details of the referred template=20
including specializations are known. This will create porting problems when=
=20
programmers forget typename. This issue is however only vaguely connected=
=20
to my question. I can't imagine that the compiler, after having parsed the=
=20
<type_traits> header would have no information that there is a typedef=20
called type in the add_const class template. Maybe the Microsoft compiler=
=20
hasn't but that has already been defined as a shortcoming. I don't see the=
=20
point in the standard continuing to prevent compilers from using this=20
information to help programmers. I have now written this up as a separate=
=20
subject, so there is no point in discussing it further here.

Den onsdagen den 4:e september 2013 kl. 02:53:50 UTC+2 skrev R. Martinho=20
Fernandes:
>
> On Tue, Sep 3, 2013 at 9:39 PM, Bengt Gustafsson=20
> <bengt.gu...@beamways.com <javascript:>> wrote:=20
> >> >> These two are different things... Personally, I'm okay with=20
> >> >> `is_const<MyType>()` or `is_const<MyType>::value` in the exceedingl=
y=20
> >> >> rare occasions where `is_const<MyType>()` doesn't cut it. I do a lo=
t=20
> >> >> of TMP, and most of the time I just write `is_const<MyType>` anyway=
,=20
> >> >> so I consider this is not-a-problem. Note that *this is still in a=
=20
> >> >> world without the C++14 aliases*.=20
> >> >=20
> >> > Are you referring to variable templates here (which would get rid of=
=20
> the=20
> >> > trailing() needed for constexpr function implementation?). Either wa=
y=20
> I=20
> >> > don't understand your point, aren't we discussing new C++14 features=
=20
> >> > here?=20
> >> > If so they should be able to use other C++14 features.=20
> >>=20
> >> No, I am not referring to variable templates. I am referring to=20
> >> passing `is_const<MyType>` as a type.=20
> >=20
> > Ok, let's see, you are passing is_const<MyType> as a type to some=20
> template.=20
> > This template would have to know that the template parameter it gets ha=
s=20
> > only one member and that is ::value. Now there are around 10 dfferent=
=20
> class=20
> > templates that could be useful for passing like this. Sorry, but I stil=
l=20
> > don't understand your point. I re-read your text above several times bu=
t=20
> it=20
> > is too vauge, and also inconsistent in that you say that you write=20
> > `is_const<MyType>()` instead of `is_const<MyType>()`. Obviously you are=
=20
> > doing TMP in very different areas than I have. As is_const<T>::value is=
=20
> > static I don't see much of a point in instantiating is_const, and if yo=
u=20
> do=20
> > you are stepping out of the TMP realm anyway.=20
>
> I don't say I write `is_const<MyType>()` instead of=20
> `is_const<MyType>()`. You should probably re-read the text once more,=20
> this time paying attention to the use of parentheses.=20
>
> I said I don't have a problem with writing `is_const<MyType>()`=20
> ("Personally, I'm okay with=20
> `is_const<MyType>()`"). However, `is_const<MyType>()` doesn't work in=20
> all cases (because it relies on a conversion to bool, which doesn't=20
> happen in all contexts). In those rare cases, I don't mind writing=20
> ``is_const<MyType>::value` instead ("or `is_const<MyType>::value` in=20
> the exceedingly rare occasions where `is_const<MyType>()` doesn't cut=20
> it."). Those cases are exceedingly rare because I pretty much never=20
> actually want to use `is_const<MyType>()` ("I do a lot of TMP, and=20
> most of the time I just write `is_const<MyType>` anyway). All my=20
> metafunctions that need some bool parameter take a "meta-bool"=20
> parameter instead (what the standard calls a UnaryTypeTrait with a=20
> bool value), so I need neither parentheses nor ::value. It has the=20
> added benefits of resulting in client code with less syntactic noise=20
> (like `EnableIf<is_const<T>>`). It is also usable in templates that=20
> take `template <typename...> class` template arguments, even if those=20
> aren't great and there are better alternatives for higher-order=20
> metafunctions (see Boost.Mpl).=20
>
> >> type_traits<T>::add_const, where T is a template parameter, is a=20
> >> dependent name. It's **exactly the same** reason add_const<T>::type=20
> >> requires the disambiguator. They both have the form A<T>::C where T is=
=20
> >> a template parameter and C is a nested type.=20
> >>=20
> >> > In this case you can't=20
> >> > compile your code without the <type_traits> include which shows the=
=20
> >> > compiler=20
> >> > that add_const::type is indeed a type and not a variable or function=
..=20
> >>=20
> >> No, the #include does not show anything like that to the compiler.=20
> >> This Stack Overflow answer=20
> >>=20
> >>=20
> http://stackoverflow.com/questions/610245/where-and-why-do-i-have-to-put-=
the-template-and-typename-keywords/613132#613132=20
> >> is recommended reading.=20
> >>=20
> > I'm of course fully aware of the basics of disambiguiation and why it i=
s=20
> > needed. The problem is that I find that at least VS2012 requires it eve=
n=20
> > when it knows full well that it is a type.=20
>
> I feel like I am wasting my time on this. To prevent further waste, I=20
> will be totally blunt: no, you are not fully aware of this issue. The=20
> compiler doesn't know full well that it is a type until instantiation,=20
> and MSVC is famous for not requiring typename when it should (because=20
> it doesn't implement two-phase lookup), not the other way around. See=20
> bug report closed as "Deferred":=20
>
> https://connect.microsoft.com/VisualStudio/feedback/details/742478/suppor=
t-two-phase-name-lookup.=20
>
>
> > You claim that for type_traits<MyType>::add_const a 'typename' would be=
=20
> > required, in places where it would not for add_const<MyType>::type. Thi=
s=20
> > makes no sense at all to me. The constructs are totally similar, a=20
> typedef=20
> > inside a known class template instantiated for a (potentially) unknown=
=20
> type.=20
>
> I don't claim any of that, and this slander is the reason I am=20
> bothering to write this reply at all. Right there in a part you quoted=20
> from my reply (so you can't even claim to not have noticed it!) are=20
> phrases like: "It's **exactly the same** reason add_const<T>::type=20
> requires the disambiguator" and "They both have the form [X]". Notice=20
> the use of the word "both" and the use of double asterisks around=20
> "exactly the same" for emphasis. There is also a distinct lack of=20
> words like "but" or "however" in that paragraph. How anyone can draw=20
> the conclusion that I see the two as different? I have no idea, and=20
> that's exactly why I am walking away from this fruitless discussion.=20
>
> Mit freundlichen Gr=FC=DFen,=20
>
> Martinho=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_5633_10524545.1378281980699
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, not to waste too much of youtr time, you were right, a=
fter about four more re-reads I could decipher your text about the trailing=
 () into something logical. It was the or not being ment as being alternati=
ves between the two adjoining quoted examples but in a longer part of the s=
entence that fooled me. Clearly I should expect a programming language expe=
rt like you to be able to write prose exactly right, although I still think=
 the wording was a bit contrived.<div><br></div><div>And I made a fool of m=
yself again on the second issue regarding the typename. I was assuming that=
 you were claiming this as a drawback for the type_traits&lt;T&gt; solution=
 as the argument "these two solutions have the same disadvantage and theref=
ore solution A is better" didn't seem to be a rational argument. As far as =
I remember I wasn't claiming any reduction in the use of 'typename' for my =
solution.</div><div><br></div><div>Of course, with the current language spe=
cification the Microsoft compiler is too lenient on typename, and in contra=
st with its other shortcomings in this area it does not show up as an error=
 message at the time of actual instantiation as by that time all the detail=
s of the referred template including specializations are known. This will c=
reate porting problems when programmers forget typename. This issue is howe=
ver only vaguely connected to my question. I can't imagine that the compile=
r, after having parsed the &lt;type_traits&gt; header would have no informa=
tion that there is a typedef called type in the add_const class template. M=
aybe the Microsoft compiler hasn't but that has already been defined as a s=
hortcoming. I don't see the point in the standard continuing to prevent com=
pilers from using this information to help programmers. I have now written =
this up as a separate subject, so there is no point in discussing it furthe=
r here.</div><br>Den onsdagen den 4:e september 2013 kl. 02:53:50 UTC+2 skr=
ev R. Martinho Fernandes:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tu=
e, Sep 3, 2013 at 9:39 PM, Bengt Gustafsson
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
GvQKArOiyZIJ">bengt.gu...@beamways.com</a><wbr>&gt; wrote:
<br>&gt;&gt; &gt;&gt; These two are different things... Personally, I'm oka=
y with
<br>&gt;&gt; &gt;&gt; `is_const&lt;MyType&gt;()` or `is_const&lt;MyType&gt;=
::value` in the exceedingly
<br>&gt;&gt; &gt;&gt; rare occasions where `is_const&lt;MyType&gt;()` doesn=
't cut it. I do a lot
<br>&gt;&gt; &gt;&gt; of TMP, and most of the time I just write `is_const&l=
t;MyType&gt;` anyway,
<br>&gt;&gt; &gt;&gt; so I consider this is not-a-problem. Note that *this =
is still in a
<br>&gt;&gt; &gt;&gt; world without the C++14 aliases*.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Are you referring to variable templates here (which would=
 get rid of the
<br>&gt;&gt; &gt; trailing() needed for constexpr function implementation?)=
.. Either way I
<br>&gt;&gt; &gt; don't understand your point, aren't we discussing new C++=
14 features
<br>&gt;&gt; &gt; here?
<br>&gt;&gt; &gt; If so they should be able to use other C++14 features.
<br>&gt;&gt;
<br>&gt;&gt; No, I am not referring to variable templates. I am referring t=
o
<br>&gt;&gt; passing `is_const&lt;MyType&gt;` as a type.
<br>&gt;
<br>&gt; Ok, let's see, you are passing is_const&lt;MyType&gt; as a type to=
 some template.
<br>&gt; This template would have to know that the template parameter it ge=
ts has
<br>&gt; only one member and that is ::value. Now there are around 10 dffer=
ent class
<br>&gt; templates that could be useful for passing like this. Sorry, but I=
 still
<br>&gt; don't understand your point. I re-read your text above several tim=
es but it
<br>&gt; is too vauge, and also inconsistent in that you say that you write
<br>&gt; `is_const&lt;MyType&gt;()` instead of `is_const&lt;MyType&gt;()`. =
Obviously you are
<br>&gt; doing TMP in very different areas than I have. As is_const&lt;T&gt=
;::value is
<br>&gt; static I don't see much of a point in instantiating is_const, and =
if you do
<br>&gt; you are stepping out of the TMP realm anyway.
<br>
<br>I don't say I write `is_const&lt;MyType&gt;()` instead of
<br>`is_const&lt;MyType&gt;()`. You should probably re-read the text once m=
ore,
<br>this time paying attention to the use of parentheses.
<br>
<br>I said I don't have a problem with writing `is_const&lt;MyType&gt;()`
<br>("Personally, I'm okay with
<br>`is_const&lt;MyType&gt;()`"). However, `is_const&lt;MyType&gt;()` doesn=
't work in
<br>all cases (because it relies on a conversion to bool, which doesn't
<br>happen in all contexts). In those rare cases, I don't mind writing
<br>``is_const&lt;MyType&gt;::value` instead ("or `is_const&lt;MyType&gt;::=
value` in
<br>the exceedingly rare occasions where `is_const&lt;MyType&gt;()` doesn't=
 cut
<br>it."). Those cases are exceedingly rare because I pretty much never
<br>actually want to use `is_const&lt;MyType&gt;()` ("I do a lot of TMP, an=
d
<br>most of the time I just write `is_const&lt;MyType&gt;` anyway). All my
<br>metafunctions that need some bool parameter take a "meta-bool"
<br>parameter instead (what the standard calls a UnaryTypeTrait with a
<br>bool value), so I need neither parentheses nor ::value. It has the
<br>added benefits of resulting in client code with less syntactic noise
<br>(like `EnableIf&lt;is_const&lt;T&gt;&gt;`). It is also usable in templa=
tes that
<br>take `template &lt;typename...&gt; class` template arguments, even if t=
hose
<br>aren't great and there are better alternatives for higher-order
<br>metafunctions (see Boost.Mpl).
<br>
<br>&gt;&gt; type_traits&lt;T&gt;::add_const, where T is a template paramet=
er, is a
<br>&gt;&gt; dependent name. It's **exactly the same** reason add_const&lt;=
T&gt;::type
<br>&gt;&gt; requires the disambiguator. They both have the form A&lt;T&gt;=
::C where T is
<br>&gt;&gt; a template parameter and C is a nested type.
<br>&gt;&gt;
<br>&gt;&gt; &gt; In this case you can't
<br>&gt;&gt; &gt; compile your code without the &lt;type_traits&gt; include=
 which shows the
<br>&gt;&gt; &gt; compiler
<br>&gt;&gt; &gt; that add_const::type is indeed a type and not a variable =
or function.
<br>&gt;&gt;
<br>&gt;&gt; No, the #include does not show anything like that to the compi=
ler.
<br>&gt;&gt; This Stack Overflow answer
<br>&gt;&gt;
<br>&gt;&gt; <a href=3D"http://stackoverflow.com/questions/610245/where-and=
-why-do-i-have-to-put-the-template-and-typename-keywords/613132#613132" tar=
get=3D"_blank">http://stackoverflow.com/<wbr>questions/610245/where-and-<wb=
r>why-do-i-have-to-put-the-<wbr>template-and-typename-<wbr>keywords/613132#=
613132</a>
<br>&gt;&gt; is recommended reading.
<br>&gt;&gt;
<br>&gt; I'm of course fully aware of the basics of disambiguiation and why=
 it is
<br>&gt; needed. The problem is that I find that at least VS2012 requires i=
t even
<br>&gt; when it knows full well that it is a type.
<br>
<br>I feel like I am wasting my time on this. To prevent further waste, I
<br>will be totally blunt: no, you are not fully aware of this issue. The
<br>compiler doesn't know full well that it is a type until instantiation,
<br>and MSVC is famous for not requiring typename when it should (because
<br>it doesn't implement two-phase lookup), not the other way around. See
<br>bug report closed as "Deferred":
<br><a href=3D"https://connect.microsoft.com/VisualStudio/feedback/details/=
742478/support-two-phase-name-lookup" target=3D"_blank">https://connect.mic=
rosoft.com/<wbr>VisualStudio/feedback/details/<wbr>742478/support-two-phase=
-name-<wbr>lookup</a>.
<br>
<br>&gt; You claim that for type_traits&lt;MyType&gt;::add_const a 'typenam=
e' would be
<br>&gt; required, in places where it would not for add_const&lt;MyType&gt;=
::type. This
<br>&gt; makes no sense at all to me. The constructs are totally similar, a=
 typedef
<br>&gt; inside a known class template instantiated for a (potentially) unk=
nown type.
<br>
<br>I don't claim any of that, and this slander is the reason I am
<br>bothering to write this reply at all. Right there in a part you quoted
<br>from my reply (so you can't even claim to not have noticed it!) are
<br>phrases like: "It's **exactly the same** reason add_const&lt;T&gt;::typ=
e
<br>requires the disambiguator" and "They both have the form [X]". Notice
<br>the use of the word "both" and the use of double asterisks around
<br>"exactly the same" for emphasis. There is also a distinct lack of
<br>words like "but" or "however" in that paragraph. How anyone can draw
<br>the conclusion that I see the two as different? I have no idea, and
<br>that's exactly why I am walking away from this fruitless discussion.
<br>
<br>Mit freundlichen Gr=FC=DFen,
<br>
<br>Martinho
<br></blockquote></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_5633_10524545.1378281980699--

.