Topic: Standard using declatarions.
Author: tomaszkam@gmail.com
Date: Tue, 28 May 2013 05:41:13 -0700 (PDT)
Raw View
------=_Part_104_1694342.1369744873231
Content-Type: text/plain; charset=ISO-8859-1
The accepted part of the TransformationTraits Redux, v2<http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf>add new template aliases for <type_traits> header, which are pretty useful,
but I have one concern - the syntax. The concepts lite proposal defines
similar template aliases for a iterator_traits members, example:
template <class T>
using remove_reference_t= typename remove_reference<T>::type;
template<typename I>
using Value_type = typename std::iterator_traits<I>::value_type;
I think it would be better for the programmers if the standard choose one
consistent syntax for the template aliases, personally I prefer the names
starting with the capital letter, but I we want to go that direction the
C++14 CD should be changed before shipping:
template <class T>
using Remove_reference = typename remove_reference<T>::type;
template<typename I>
using Value_type = typename std::iterator_traits<I>::value_type;
Similar consistency problem exists between Type Traits Variables<https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/QOYLLJjH98k>and concepts lite functions.
What do you think about this name changes? Is there any chance to change it
before C++14 is shipped and if so, how it should be done?
--
---
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/?hl=en.
------=_Part_104_1694342.1369744873231
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The accepted part of the <a href=3D"http://www.open-std.org/JTC1/sc22/wg21/=
docs/papers/2013/n3655.pdf">TransformationTraits Redux, v2</a> add new temp=
late aliases for <type_traits> header, which are pretty useful, but I=
have one concern - the syntax. The concepts lite proposal defines similar =
template aliases for a iterator_traits members, example:<br><span style=3D"=
font-family: courier new,monospace;">template <class T><br>using remo=
ve_reference_t=3D typename remove_reference<T>::type;<br><br>template=
<typename I><br>using Value_type =3D typename std::iterator_traits<=
;I>::value_type;</span><br><br>I think it would be better for the progra=
mmers if the standard choose one consistent syntax for the template aliases=
, personally I prefer the names starting with the capital letter, but I we =
want to go that direction the C++14 CD should be changed before shipping:<b=
r><span style=3D"font-family: courier new,monospace;">template <class T&=
gt;<br>using Remove_reference =3D typename remove_reference<T>::type;=
<br><br>template<typename I><br>using Value_type =3D typename std::it=
erator_traits<I>::value_type;</span><br><br>Similar consistency probl=
em exists between <a href=3D"https://groups.google.com/a/isocpp.org/forum/?=
fromgroups=3D#!topic/std-proposals/QOYLLJjH98k">Type Traits Variables</a> a=
nd concepts lite functions.<br><br>What do you think about this name change=
s? Is there any chance to change it before C++14 is shipped and if so, how =
it should be done?<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_104_1694342.1369744873231--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Tue, 28 May 2013 06:29:44 -0700 (PDT)
Raw View
------=_Part_356_1879739.1369747784916
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 1:41:13 PM UTC+1, toma...@gmail.com wrote:
>
>
> Is there any chance to change it before C++14 is shipped and if so, how
> it should be done?
>
National Bodies will submit comments on the draft and the committee will
respond to those comments, possibly by changing the draft.
--
---
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/?hl=en.
------=_Part_356_1879739.1369747784916
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 1:41:13 PM UTC+1, toma...@gmail.com wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><br> Is there any chance to chang=
e it before C++14 is shipped and if so, how it should be done?<br></blockqu=
ote><div><br>National Bodies will submit comments on the draft and the comm=
ittee will respond to those comments, possibly by changing the draft. =
<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_356_1879739.1369747784916--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 May 2013 06:30:58 -0700 (PDT)
Raw View
------=_Part_3691_20880501.1369747858468
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, May 28, 2013 5:41:13 AM UTC-7, toma...@gmail.com wrote:
>
> The accepted part of the TransformationTraits Redux, v2<http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf>add new template aliases for <type_traits> header, which are pretty useful,
> but I have one concern - the syntax. The concepts lite proposal defines
> similar template aliases for a iterator_traits members, example:
> template <class T>
> using remove_reference_t= typename remove_reference<T>::type;
>
> template<typename I>
> using Value_type = typename std::iterator_traits<I>::value_type;
>
> I think it would be better for the programmers if the standard choose one
> consistent syntax for the template aliases, personally I prefer the names
> starting with the capital letter, but I we want to go that direction the
> C++14 CD should be changed before shipping:
> template <class T>
> using Remove_reference = typename remove_reference<T>::type;
>
> template<typename I>
> using Value_type = typename std::iterator_traits<I>::value_type;
>
> Similar consistency problem exists between Type Traits Variables<https://groups.google.com/a/isocpp.org/forum/?fromgroups=#!topic/std-proposals/QOYLLJjH98k>and concepts lite functions.
>
> What do you think about this name changes? Is there any chance to change
> it before C++14 is shipped and if so, how it should be done?
>
I highly doubt the committee is going to allow concepts lite to introduce
constructs that don't fit into the established C++ conventions. So either
the committee will change those constructs to fit established conventions,
or they'll change the conventions to fit the concepts lite definition.
Personally, I would prefer that only actual *concepts* use upper case
lettering. `std::remove_referent<T>::type` is just a type (OK, technically
it's a template with a template argument T that resolves to a type, but you
get my point); it's nothing special. So it should fit into the established
conventions for a type.
--
---
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/?hl=en.
------=_Part_3691_20880501.1369747858468
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 5:41:13 AM UTC-7, toma...@gmail.com wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">The accepted part of the <a href=3D"ht=
tp://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf" target=3D"=
_blank">TransformationTraits Redux, v2</a> add new template aliases for <=
;type_traits> header, which are pretty useful, but I have one concern - =
the syntax. The concepts lite proposal defines similar template aliases for=
a iterator_traits members, example:<br><span style=3D"font-family:courier =
new,monospace">template <class T><br>using remove_reference_t=3D type=
name remove_reference<T>::type;<br><br>template<typename I><br>=
using Value_type =3D typename std::iterator_traits<I>::<wbr>value_typ=
e;</span><br><br>I think it would be better for the programmers if the stan=
dard choose one consistent syntax for the template aliases, personally I pr=
efer the names starting with the capital letter, but I we want to go that d=
irection the C++14 CD should be changed before shipping:<br><span style=3D"=
font-family:courier new,monospace">template <class T><br>using Remove=
_reference =3D typename remove_reference<T>::type;<br><br>template<=
;typename I><br>using Value_type =3D typename std::iterator_traits<I&=
gt;::<wbr>value_type;</span><br><br>Similar consistency problem exists betw=
een <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgroups=3D#=
!topic/std-proposals/QOYLLJjH98k" target=3D"_blank">Type Traits Variables</=
a> and concepts lite functions.<br><br>What do you think about this name ch=
anges? Is there any chance to change it before C++14 is shipped and if so, =
how it should be done?<br></blockquote><div><br>I highly doubt the committe=
e is going to allow concepts lite to introduce constructs that don't fit in=
to the established C++ conventions. So either the committee will change tho=
se constructs to fit established conventions, or they'll change the convent=
ions to fit the concepts lite definition.<br><br>Personally, I would prefer=
that only actual <i>concepts</i> use upper case lettering. `std::remove_re=
ferent<T>::type` is just a type (OK, technically it's a template with=
a template argument T that resolves to a type, but you get my point); it's=
nothing special. So it should fit into the established conventions for a t=
ype.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3691_20880501.1369747858468--
.
Author: tomaszkam@gmail.com
Date: Tue, 28 May 2013 12:07:50 -0700 (PDT)
Raw View
------=_Part_630_27392133.1369768070695
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu wtorek, 28 maja 2013 15:30:58 UTC+2 u=BFytkownik Nicol Bolas napisa=
=B3:
>
> On Tuesday, May 28, 2013 5:41:13 AM UTC-7, toma...@gmail.com wrote:
>>
>> The accepted part of the TransformationTraits Redux, v2<http://www.open-=
std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf>add new template aliases =
for <type_traits> header, which are pretty useful,=20
>> but I have one concern - the syntax. The concepts lite proposal defines=
=20
>> similar template aliases for a iterator_traits members, example:
>> template <class T>
>> using remove_reference_t=3D typename remove_reference<T>::type;
>>
>> template<typename I>
>> using Value_type =3D typename std::iterator_traits<I>::value_type;
>>
>> I think it would be better for the programmers if the standard choose on=
e=20
>> consistent syntax for the template aliases, personally I prefer the name=
s=20
>> starting with the capital letter, but I we want to go that direction the=
=20
>> C++14 CD should be changed before shipping:
>> template <class T>
>> using Remove_reference =3D typename remove_reference<T>::type;
>>
>> template<typename I>
>> using Value_type =3D typename std::iterator_traits<I>::value_type;
>>
>> Similar consistency problem exists between Type Traits Variables<https:/=
/groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-proposals/Q=
OYLLJjH98k>and concepts lite functions.
>>
>> What do you think about this name changes? Is there any chance to change=
=20
>> it before C++14 is shipped and if so, how it should be done?
>>
>
> I highly doubt the committee is going to allow concepts lite to introduce=
=20
> constructs that don't fit into the established C++ conventions. So either=
=20
> the committee will change those constructs to fit established conventions=
,=20
> or they'll change the conventions to fit the concepts lite definition.
>
> Personally, I would prefer that only actual *concepts* use upper case=20
> lettering. `std::remove_referent<T>::type` is just a type (OK, technicall=
y=20
> it's a template with a template argument T that resolves to a type, but y=
ou=20
> get my point); it's nothing special. So it should fit into the establishe=
d=20
> conventions for a type.
>
But I think the std::iterator_traits<I>::value_type is also just a type=20
(the same as std::remove_reference<T>::type), but still the Concepts-lite=
=20
uses Value_type name for a template alias - it just an alias, not any=20
constrains are put there.
--=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/?hl=3Den.
------=_Part_630_27392133.1369768070695
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu wtorek, 28 maja 2013 15:30:58 UTC+2 u=BFytkownik Nicol Bolas=
napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, May 28,=
2013 5:41:13 AM UTC-7, <a>toma...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">The accepted part of the <a href=3D"http://www.open-std=
..org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf" target=3D"_blank">Transform=
ationTraits Redux, v2</a> add new template aliases for <type_traits> =
header, which are pretty useful, but I have one concern - the syntax. The c=
oncepts lite proposal defines similar template aliases for a iterator_trait=
s members, example:<br><span style=3D"font-family:courier new,monospace">te=
mplate <class T><br>using remove_reference_t=3D typename remove_refer=
ence<T>::type;<br><br>template<typename I><br>using Value_type =
=3D typename std::iterator_traits<I>::<wbr>value_type;</span><br><br>=
I think it would be better for the programmers if the standard choose one c=
onsistent syntax for the template aliases, personally I prefer the names st=
arting with the capital letter, but I we want to go that direction the C++1=
4 CD should be changed before shipping:<br><span style=3D"font-family:couri=
er new,monospace">template <class T><br>using Remove_reference =3D ty=
pename remove_reference<T>::type;<br><br>template<typename I><b=
r>using Value_type =3D typename std::iterator_traits<I>::<wbr>value_t=
ype;</span><br><br>Similar consistency problem exists between <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-propos=
als/QOYLLJjH98k" target=3D"_blank">Type Traits Variables</a> and concepts l=
ite functions.<br><br>What do you think about this name changes? Is there a=
ny chance to change it before C++14 is shipped and if so, how it should be =
done?<br></blockquote><div><br>I highly doubt the committee is going to all=
ow concepts lite to introduce constructs that don't fit into the establishe=
d C++ conventions. So either the committee will change those constructs to =
fit established conventions, or they'll change the conventions to fit the c=
oncepts lite definition.<br><br>Personally, I would prefer that only actual=
<i>concepts</i> use upper case lettering. `std::remove_referent<T>::=
<wbr>type` is just a type (OK, technically it's a template with a template =
argument T that resolves to a type, but you get my point); it's nothing spe=
cial. So it should fit into the established conventions for a type.<br></di=
v></blockquote><div><br>But I think the std::iterator_traits<I>::valu=
e_type is also just a type (the same as std::remove_reference<T>::typ=
e), but still the Concepts-lite uses Value_type name for a template alias -=
it just an alias, not any constrains are put there.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_630_27392133.1369768070695--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 May 2013 13:05:06 -0700 (PDT)
Raw View
------=_Part_2812_32843951.1369771506174
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 12:07:50 PM UTC-7, toma...@gmail.com wrote:
>
> W dniu wtorek, 28 maja 2013 15:30:58 UTC+2 u=BFytkownik Nicol Bolas napis=
a=B3:
>>
>> On Tuesday, May 28, 2013 5:41:13 AM UTC-7, toma...@gmail.com wrote:
>>>
>>> The accepted part of the TransformationTraits Redux, v2<http://www.open=
-std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf>add new template aliases=
for <type_traits> header, which are pretty useful,=20
>>> but I have one concern - the syntax. The concepts lite proposal defines=
=20
>>> similar template aliases for a iterator_traits members, example:
>>> template <class T>
>>> using remove_reference_t=3D typename remove_reference<T>::type;
>>>
>>> template<typename I>
>>> using Value_type =3D typename std::iterator_traits<I>::value_type;
>>>
>>> I think it would be better for the programmers if the standard choose=
=20
>>> one consistent syntax for the template aliases, personally I prefer the=
=20
>>> names starting with the capital letter, but I we want to go that direct=
ion=20
>>> the C++14 CD should be changed before shipping:
>>> template <class T>
>>> using Remove_reference =3D typename remove_reference<T>::type;
>>>
>>> template<typename I>
>>> using Value_type =3D typename std::iterator_traits<I>::value_type;
>>>
>>> Similar consistency problem exists between Type Traits Variables<https:=
//groups.google.com/a/isocpp.org/forum/?fromgroups=3D#!topic/std-proposals/=
QOYLLJjH98k>and concepts lite functions.
>>>
>>> What do you think about this name changes? Is there any chance to chang=
e=20
>>> it before C++14 is shipped and if so, how it should be done?
>>>
>>
>> I highly doubt the committee is going to allow concepts lite to introduc=
e=20
>> constructs that don't fit into the established C++ conventions. So eithe=
r=20
>> the committee will change those constructs to fit established convention=
s,=20
>> or they'll change the conventions to fit the concepts lite definition.
>>
>> Personally, I would prefer that only actual *concepts* use upper case=20
>> lettering. `std::remove_referent<T>::type` is just a type (OK, technical=
ly=20
>> it's a template with a template argument T that resolves to a type, but =
you=20
>> get my point); it's nothing special. So it should fit into the establish=
ed=20
>> conventions for a type.
>>
>
> But I think the std::iterator_traits<I>::value_type is also just a type=
=20
> (the same as std::remove_reference<T>::type), but still the Concepts-lite=
=20
> uses Value_type name for a template alias - it just an alias, not any=20
> constrains are put there.
>
Are there any other aliases in all of the C++ standard library that=20
capitalize the first letter? No. So why should the alias for=20
`std::iterator_traits<T>::value_type` be any different? It's a consistent=
=20
convention of the C++ standard library that types and templates do not have=
=20
their first letter capitalized. This includes all typedefs and template=20
aliases in C++11.
I see no reason why we should suddenly go against that now. There's nothing=
=20
special about these aliases that warrants a new convention. And I'm=20
guessing/hoping that the committee will straighten that out in=20
Concepts-lite as it evolves.
Remember: it's just a proposal. It's not even part of the C++14 CD.
--=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/?hl=3Den.
------=_Part_2812_32843951.1369771506174
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On Tuesday, May 28, 2013 12:07:50 PM UTC-7, toma...@gmail.com wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">W dniu wtorek, 28 maja 2013 15:30:58 =
UTC+2 u=BFytkownik Nicol Bolas napisa=B3:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">On Tuesday, May 28, 2013 5:41:13 AM UTC-7, <a>toma...@gmail.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">The accepted part of the <a hr=
ef=3D"http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3655.pdf" ta=
rget=3D"_blank">TransformationTraits Redux, v2</a> add new template aliases=
for <type_traits> header, which are pretty useful, but I have one co=
ncern - the syntax. The concepts lite proposal defines similar template ali=
ases for a iterator_traits members, example:<br><span style=3D"font-family:=
courier new,monospace">template <class T><br>using remove_reference_t=
=3D typename remove_reference<T>::type;<br><br>template<typename I=
><br>using Value_type =3D typename std::iterator_traits<I>::<wbr>v=
alue_type;</span><br><br>I think it would be better for the programmers if =
the standard choose one consistent syntax for the template aliases, persona=
lly I prefer the names starting with the capital letter, but I we want to g=
o that direction the C++14 CD should be changed before shipping:<br><span s=
tyle=3D"font-family:courier new,monospace">template <class T><br>usin=
g Remove_reference =3D typename remove_reference<T>::type;<br><br>tem=
plate<typename I><br>using Value_type =3D typename std::iterator_trai=
ts<I>::<wbr>value_type;</span><br><br>Similar consistency problem exi=
sts between <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgr=
oups=3D#!topic/std-proposals/QOYLLJjH98k" target=3D"_blank">Type Traits Var=
iables</a> and concepts lite functions.<br><br>What do you think about this=
name changes? Is there any chance to change it before C++14 is shipped and=
if so, how it should be done?<br></blockquote><div><br>I highly doubt the =
committee is going to allow concepts lite to introduce constructs that don'=
t fit into the established C++ conventions. So either the committee will ch=
ange those constructs to fit established conventions, or they'll change the=
conventions to fit the concepts lite definition.<br><br>Personally, I woul=
d prefer that only actual <i>concepts</i> use upper case lettering. `std::r=
emove_referent<T>::<wbr>type` is just a type (OK, technically it's a =
template with a template argument T that resolves to a type, but you get my=
point); it's nothing special. So it should fit into the established conven=
tions for a type.<br></div></blockquote><div><br>But I think the std::itera=
tor_traits<I>::<wbr>value_type is also just a type (the same as std::=
remove_reference<T>::<wbr>type), but still the Concepts-lite uses Val=
ue_type name for a template alias - it just an alias, not any constrains ar=
e put there.<br></div></blockquote><div><br>Are there any other aliases in =
all of the C++ standard library that capitalize the first letter? No. So wh=
y should the alias for `std::iterator_traits<T>::value_type` be any d=
ifferent? It's a consistent convention of the C++ standard library that typ=
es and templates do not have their first letter capitalized. This includes =
all typedefs and template aliases in C++11.<br><br>I see no reason why we s=
hould suddenly go against that now. There's nothing special about these ali=
ases that warrants a new convention. And I'm guessing/hoping that the commi=
ttee will straighten that out in Concepts-lite as it evolves.<br><br>Rememb=
er: it's just a proposal. It's not even part of the C++14 CD.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2812_32843951.1369771506174--
.