------=_Part_1546_19469877.1377930929641
Content-Type: text/plain; charset=ISO-8859-1

I think that getting rid of the ::type on the different traits classes in
the standard library is a very good improvement. However, as the good names
(is_const, add_reference etc) are used by the old style classes the new
using declarationas have been fitted with a _t suffix. In ten years time we
will hopefully have forgotten that we had to write ::type everywhere in the
old days. Then it will be hard to explain the _t you have to add everywhere
with the newer language version.

So how can this be resolved? We can obviously not break all old code by
just changing the definitions of all the names. What I'm aiming to
accomplish is instead to allow programmers to state that they want to use
the new implementation rather than the original one. The logical way to do
this is a using namespace declaration. The catch is of course that a lot of
people already have a "using namespace std;" in their code, so even if they
add "using namespace std::type_traits_v2;" it will just result in a clash
when using the names.

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.

This would allow using namespace declarations to be used to select more
modern versions of features even if the original version was placed in an
outer namespace.

I am not sure if this feature should be extended to the global scope so
that std::vector is selected automatically over a user defined vector on
the root level if you have a using std. I think this will have unforeseen
consequences. It would be more consistent, however, so the implications
should be investigated before deciding.

As some may have noticed I have been sort-of advocating against taking away
the vector<bool> specialization on the grounds that it will break someones
code. The feature mentioned above can not be used to allow users to select
whether they want the specialization to be used or not. This is as you
can't have a specialization of a template class in another namespace so
using namespaces to select is not possible. At least this is what I think.
Assuming that this was allowed (I don't think it would be too scary to
allow it) the specific vector<bool> case is also strange in that you would
want to remove code rather than add it, assuming that we want backwards
compatiblity as the default. Thus:

namespace std {
    template<typename T> class vector { ...normal vector code... };

    namespace specialized_bool_vector {
        template<> class std::vector { ...vector<bool> special code... };
    }
}

using namespace std:

vector<bool> nonspecialized;

using namespace std::specialized_bool_vector;

vector<bool> specialized;

The problem is that the default behaviour is to not specialize, while (at
least for me) not breaking old code should be the default behaviour.

One possibility, although rather contrived, would be to have some unusing
possibility. For instance like this:

!using namespace std::specialized_bool_vector;

(complemented by the corresponding using inside the vector header of
course).

I think that unusing namespaces would in general be a somewhat useful
feature, but in conjunction with the most-nested-namespace-wins rule
suggested here it would provide more freedom for library changes.





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 have
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 = ...;
};

And so on. There must be some distinct advantages to outweigh that the
namespace pollution of std would have been much less and the usage would
have been cleaner as it would not have contained the ::type/::value which
is just a band aid for a missing language feature:

type_traits<MyType>::is_const

vs

is_const<MyType>::type

Finally:

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 the
standard library they are used in.

--

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

<div dir=3D"ltr">I think that getting rid of the ::type on the different tr=
aits classes in the standard library is a very good improvement. However, a=
s the good names (is_const, add_reference etc) are used by the old style cl=
asses the new using declarationas have been fitted with a _t suffix. In ten=
 years time we will hopefully have forgotten that we had to write ::type ev=
erywhere in the old days. Then it will be hard to explain the _t you have t=
o add everywhere with the newer language version.<div><br></div><div>So how=
 can this be resolved? We can obviously not break all old code by just chan=
ging the definitions of all the names. What I'm aiming to accomplish is ins=
tead to allow programmers to state that they want to use the new implementa=
tion rather than the original one. The logical way to do this is a using na=
mespace declaration. The catch is of course that a lot of people already ha=
ve a "using namespace std;" in their code, so even if they add "using names=
pace std::type_traits_v2;" it will just result in a clash when using the na=
mes.</div><div><br></div><div>My suggested solution is:</div><div><br></div=
><div>If two things with the same name are found select the name in the mos=
t nested namespace if the two conflicting namespaces are nested in each oth=
er.</div><div><br></div><div>This would allow using namespace declarations =
to be used to select more modern versions of features even if the original =
version was placed in an outer namespace.</div><div><br></div><div>I am not=
 sure if this feature should be extended to the global scope so that std::v=
ector is selected automatically over a user defined vector on the root leve=
l if you have a using std. I think this will have unforeseen consequences. =
It would be more consistent, however, so the implications should be investi=
gated before deciding.</div><div><br></div><div>As some may have noticed I =
have been sort-of advocating against taking away the vector&lt;bool&gt; spe=
cialization on the grounds that it will break someones code. The feature me=
ntioned above can not be used to allow users to select whether they want th=
e specialization to be used or not. This is as you can't have a specializat=
ion of a template class in another namespace so using namespaces to select =
is not possible. At least this is what I think. Assuming that this was allo=
wed (I don't think it would be too scary to allow it) the specific vector&l=
t;bool&gt; case is also strange in that you would want to remove code rathe=
r than add it, assuming that we want backwards compatiblity as the default.=
 Thus:</div><div><br></div><div>namespace std {</div><div>&nbsp; &nbsp; tem=
plate&lt;typename T&gt; class vector { ...normal vector code... };</div><di=
v><br></div><div>&nbsp; &nbsp; namespace specialized_bool_vector {</div><di=
v>&nbsp; &nbsp; &nbsp; &nbsp; template&lt;&gt; class std::vector { ...vecto=
r&lt;bool&gt; special code... };</div><div>&nbsp; &nbsp; }</div><div>}</div=
><div><br></div><div>using namespace std:</div><div><br></div><div>vector&l=
t;bool&gt; nonspecialized;</div><div><br></div><div>using namespace std::<s=
pan style=3D"font-size: 13px;">specialized_bool_vector;</span></div><div><s=
pan style=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-si=
ze: 13px;">vector&lt;bool&gt; specialized;</span></div><div><span style=3D"=
font-size: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">Th=
e problem is that the default behaviour is to not specialize, while (at lea=
st for me) not breaking old code should be the default behaviour.</span></d=
iv><div><span style=3D"font-size: 13px;"><br></span></div><div><span style=
=3D"font-size: 13px;">One possibility, although rather contrived, would be =
to have some unusing possibility. For instance like this:</span></div><div>=
<span style=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-=
size: 13px;">!using namespace std::specialized_bool_vector;</span></div><di=
v><span style=3D"font-size: 13px;"><br></span></div><div><span style=3D"fon=
t-size: 13px;">(complemented by the corresponding using inside the vector h=
eader of course).</span></div><div><span style=3D"font-size: 13px;"><br></s=
pan></div><div><span style=3D"font-size: 13px;">I think that unusing namesp=
aces would in general be a somewhat useful feature, but in conjunction with=
 the most-nested-namespace-wins rule suggested here it would provide more f=
reedom for library changes.</span></div><div><span style=3D"font-size: 13px=
;"><br></span></div><div><span style=3D"font-size: 13px;"><br></span></div>=
<div>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div><div><br></div><div><br></div><=
div>As an aside: Could anyone explain to me why type_traits ended up as a m=
ultitude of single purpose structs in the first place. To me it would have =
been more logical to have one type_traits template like this:</div><div><br=
></div><div><br></div><div>template &lt;typename T&gt; struct type_traits {=
</div><div><span style=3D"font-size: 13px;">&nbsp; &nbsp; typedef const T a=
dd_const;</span></div><div>&nbsp; &nbsp; static const bool is_const =3D ...=
;</div><div><span style=3D"font-size: 13px;">};</span><br></div><div><br></=
div><div>And so on. There must be some distinct advantages to outweigh that=
 the namespace pollution of std would have been much less and the usage wou=
ld have been cleaner as it would not have contained the ::type/::value whic=
h is just a band aid for a missing language feature:</div><div><br></div><d=
iv>type_traits&lt;MyType&gt;::is_const</div><div><br></div><div>vs</div><di=
v><br></div><div>is_const&lt;MyType&gt;::type</div><div><br></div><div>Fina=
lly:</div><div><br></div><div>I assume that now with template variables com=
ing 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 a=
nd the ::value be done in the same language version upgrade, and that the s=
ame change is done for ALL instances of ::type and ::value constructs, rega=
rdless of what part of the standard library they are used in.&nbsp;</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_1546_19469877.1377930929641--

.