Topic: Factored cv-qualifier
Author: John Yates <john@yates-sheets.org>
Date: Mon, 13 Jul 2015 09:30:15 -0400
Raw View
--bcaec548ab25d1bd26051ac1b8c8
Content-Type: text/plain; charset=UTF-8
*Summary*
Extend the syntax of aggregate declarations to allow a factored
cv-qualifier:
*class-key attr class-head-name cv-qualifier base-clause* *{* *body*
> *}**union** attr class-head-name cv-qualifier* *{* *body*
> *}*
*Discussion*
This proposal introduces no new semantics. It is pure syntactic sugar.
That said it allows one to more clearly declare the semantics of an
aggregate.
The overall const-ness of an aggregate is part of its public interface. It
allows one to know that after having constructed an object and passed it
around it remains intact.
Today this overall const-ness property can be ascertained only by an
exhaustive inspection of an aggregate's data members. Given a style which
makes all data private and orders an aggregate's body sections { public:,
protected:, private: } knowledge of this public property is encoded far
from the rest of the public interface.
Further, even after exhaustive inspection (modulo a comment stating that
all new data members must be declared const) it is unclear to a maintainer
whether all existing data members being const requires new data members
also to be const.
/john
--
---
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/.
--bcaec548ab25d1bd26051ac1b8c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font size=3D"4"><b>Summary</b></font><div><br></div><div>=
Extend the syntax of aggregate declarations to allow a factored cv-qualifie=
r:<div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><font face=3D"monospace, monospace"><i>class-ke=
y attr class-head-name <font color=3D"#0000ff">cv-qualifier</font> base-cla=
use</i> <b>{</b> <i>body</i> <b>}<br></b></font><font face=3D"monospace, mo=
nospace"><b>union</b><i> =C2=A0 =C2=A0 attr class-head-name <font color=3D"=
#0000ff">cv-qualifier</font></i> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
<b>{</b> <i>body</i> <b>}</b></font></blockquote></div><br></div><div><font=
size=3D"4"><b>Discussion</b></font></div><div><br></div><div>This proposal=
introduces no new semantics.=C2=A0 It is pure syntactic sugar.=C2=A0 That =
said it allows one to more clearly declare the semantics of an aggregate.</=
div><div><br></div><div>The overall const-ness of an aggregate is part of i=
ts public interface.=C2=A0 It allows one to know that after having construc=
ted an object and passed it around it remains intact.</div><div><br></div><=
div>Today this overall const-ness property can be ascertained only by an ex=
haustive inspection of an aggregate's data members.=C2=A0 Given a style=
which makes all data private and orders an aggregate's body sections {=
public:, protected:, private: } knowledge of this public property is encod=
ed far from the rest of the public interface.</div><div><br></div><div>Furt=
her, even after exhaustive inspection (modulo a comment stating that all ne=
w data members must be declared const) it is unclear to a maintainer whethe=
r all existing data members being const requires new data members also to b=
e const.</div><div><br></div><div>/john</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec548ab25d1bd26051ac1b8c8--
.
Author: Miro Knejp <miro.knejp@gmail.com>
Date: Mon, 13 Jul 2015 15:43:47 +0200
Raw View
--Apple-Mail=_CE9F7E24-51CA-4A0E-8985-C20E00533A25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 13 Jul 2015, at 15:30 , John Yates <john@yates-sheets.org> wrote:
>=20
> Summary
>=20
> Extend the syntax of aggregate declarations to allow a factored cv-qualif=
ier:
>=20
> class-key attr class-head-name cv-qualifier base-clause { body }
> union attr class-head-name cv-qualifier { body }
>=20
> Discussion
>=20
> This proposal introduces no new semantics.=20
If it has no new semantics it probably should be an attribute.
> It is pure syntactic sugar. That said it allows one to more clearly dec=
lare the semantics of an aggregate.
>=20
> The overall const-ness of an aggregate is part of its public interface. =
It allows one to know that after having constructed an object and passed it=
around it remains intact.
>=20
> Today this overall const-ness property can be ascertained only by an exha=
ustive inspection of an aggregate's data members. Given a style which make=
s all data private and orders an aggregate's body sections { public:, prote=
cted:, private: } knowledge of this public property is encoded far from the=
rest of the public interface.
>=20
> Further, even after exhaustive inspection (modulo a comment stating that =
all new data members must be declared const) it is unclear to a maintainer =
whether all existing data members being const requires new data members als=
o to be const.
Then why not give the qualifier semantics and make it enforce it on all dat=
a members/methods? Otherwise it seems rather pointless. If the qualifier do=
esn=E2=80=99t do anything then all it=E2=80=99s good for is maybe a compile=
r warning, and that can be done with an attribute that doesn=E2=80=99t touc=
h any grammar rules.
>=20
> /john
>=20
> --=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=
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubs=
cribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_CE9F7E24-51CA-4A0E-8985-C20E00533A25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
r class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 1=
3 Jul 2015, at 15:30 , John Yates <<a href=3D"mailto:john@yates-sheets.o=
rg" class=3D"">john@yates-sheets.org</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D""><font siz=
e=3D"4" class=3D""><b class=3D"">Summary</b></font><div class=3D""><br clas=
s=3D""></div><div class=3D"">Extend the syntax of aggregate declarations to=
allow a factored cv-qualifier:<div class=3D""><br class=3D""><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><font face=3D"monospace, monospace" class=3D""><i class=3D"">class-key =
attr class-head-name <font color=3D"#0000ff" class=3D"">cv-qualifier</font>=
base-clause</i> <b class=3D"">{</b> <i class=3D"">body</i> <b class=3D"">}=
<br class=3D""></b></font><font face=3D"monospace, monospace" class=3D""><b=
class=3D"">union</b><i class=3D""> attr class-head-name <fon=
t color=3D"#0000ff" class=3D"">cv-qualifier</font></i> =
<b class=3D"">{</b> <i class=3D"">body</i> <b class=
=3D"">}</b></font></blockquote></div><br class=3D""></div><div class=3D""><=
font size=3D"4" class=3D""><b class=3D"">Discussion</b></font></div><div cl=
ass=3D""><br class=3D""></div><div class=3D"">This proposal introduces no n=
ew semantics. </div></div></div></blockquote><div><br class=3D""></div=
>If it has no new semantics it probably should be an attribute.</div><div c=
lass=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D=
""><div dir=3D"ltr" class=3D""><div class=3D""> It is pure syntactic s=
ugar. That said it allows one to more clearly declare the semantics o=
f an aggregate.</div><div class=3D""><br class=3D""></div><div class=3D"">T=
he overall const-ness of an aggregate is part of its public interface. =
; It allows one to know that after having constructed an object and passed =
it around it remains intact.</div><div class=3D""><br class=3D""></div><div=
class=3D"">Today this overall const-ness property can be ascertained only =
by an exhaustive inspection of an aggregate's data members. Given a s=
tyle which makes all data private and orders an aggregate's body sections {=
public:, protected:, private: } knowledge of this public property is encod=
ed far from the rest of the public interface.</div><div class=3D""><br clas=
s=3D""></div><div class=3D"">Further, even after exhaustive inspection (mod=
ulo a comment stating that all new data members must be declared const) it =
is unclear to a maintainer whether all existing data members being const re=
quires new data members also to be const.</div></div></div></blockquote><di=
v class=3D""><br class=3D""></div>Then why not give the qualifier semantics=
and make it enforce it on all data members/methods? Otherwise it seems rat=
her pointless. If the qualifier doesn=E2=80=99t do anything then all it=E2=
=80=99s good for is maybe a compiler warning, and that can be done with an =
attribute that doesn=E2=80=99t touch any grammar rules.</div><div class=3D"=
"><br class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div class=3D""><br class=3D""></div><div class=3D""=
>/john</div></div><div class=3D""><br class=3D"webkit-block-placeholder"></=
div>
-- <br class=3D"">
<br class=3D"">
--- <br class=3D"">
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">=
std-proposals+unsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" class=3D"">http://groups.google.com/a/isocpp.org/group/std-=
proposals/</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_CE9F7E24-51CA-4A0E-8985-C20E00533A25--
.
Author: John Yates <john@yates-sheets.org>
Date: Mon, 13 Jul 2015 10:30:41 -0400
Raw View
--001a1136ac12f98ba3051ac2909c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Jul 13, 2015 at 9:43 AM, Miro Knejp <miro.knejp@gmail.com> wrote:
>
> On 13 Jul 2015, at 15:30 , John Yates <john@yates-sheets.org> wrote:
>
> *Summary*
>
> Extend the syntax of aggregate declarations to allow a factored
> cv-qualifier:
>
> *class-key attr class-head-name cv-qualifier base-clause* *{* *body*
>> *}**union** attr class-head-name cv-qualifier* *{* *body=
*
>> *}*
>
>
> *Discussion*
>
> This proposal introduces no new semantics.
>
>
> If it has no new semantics it probably should be an attribute.
>
Notice the title of the proposal: "Factored cv-qualifier". I did not say
that the construct has no semantics, only that it does not allow one to
express anything that one could not already have expressed by qualifying
every single data and function member. I should have stated clearly that
once a cv-qualifier appears in an aggregate heading supplying that same
cv-qualifier within that aggregate's body is redundant and hence can be
omitted.
I could live with it being an attribute. OTOH the attribute syntax exists
in part to allow problem-free introduction over time of arbitrary new
identifiers. const (and volatile) are already reserved words so they do
not need to be shielded so. Finally I find
class MyObject const { ... };
easier to scan than
class [[const]] MyObject { ... };
(Though that may be because I consistently place my cv-qualifiers to the
right of the type they are qualifying.)
It is pure syntactic sugar. That said it allows one to more clearly
> declare the semantics of an aggregate.
>
> The overall const-ness of an aggregate is part of its public interface.
> It allows one to know that after having constructed an object and passed =
it
> around it remains intact.
>
> Today this overall const-ness property can be ascertained only by an
> exhaustive inspection of an aggregate's data members. Given a style whic=
h
> makes all data private and orders an aggregate's body sections { public:,
> protected:, private: } knowledge of this public property is encoded far
> from the rest of the public interface.
>
> Further, even after exhaustive inspection (modulo a comment stating that
> all new data members must be declared const) it is unclear to a maintaine=
r
> whether all existing data members being const requires new data members
> also to be const.
>
>
> Then why not give the qualifier semantics and make it enforce it on all
> data members/methods? Otherwise it seems rather pointless. If the qualifi=
er
> doesn=E2=80=99t do anything then all it=E2=80=99s good for is maybe a com=
piler warning, and
> that can be done with an attribute that doesn=E2=80=99t touch any grammar=
rules.
>
I believe that we are "in violent agreement" (see above).
>
>
> /john
>
> --
>
> ---
> 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/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1136ac12f98ba3051ac2909c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 13, 2015 at 9:43 AM, Miro Knejp <span dir=3D"ltr"><<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><=
br><div><span><blockquote type=3D"cite"><div>On 13 Jul 2015, at 15:30 , Joh=
n Yates <<a href=3D"mailto:john@yates-sheets.org" target=3D"_blank">john=
@yates-sheets.org</a>> wrote:</div><br><div><div dir=3D"ltr"><font size=
=3D"4"><b>Summary</b></font><div><br></div><div>Extend the syntax of aggreg=
ate declarations to allow a factored cv-qualifier:<div><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><font face=3D"monospace, monospace"><i>class-key attr class-head-name <fon=
t color=3D"#0000ff">cv-qualifier</font> base-clause</i> <b>{</b> <i>body</i=
> <b>}<br></b></font><font face=3D"monospace, monospace"><b>union</b><i> =
=C2=A0 =C2=A0 attr class-head-name <font color=3D"#0000ff">cv-qualifier</fo=
nt></i> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <b>{</b> <i>body</i> <b>}=
</b></font></blockquote></div><br></div><div><font size=3D"4"><b>Discussion=
</b></font></div><div><br></div><div>This proposal introduces no new semant=
ics.=C2=A0</div></div></div></blockquote><div><br></div></span>If it has no=
new semantics it probably should be an attribute.</div></div></div></block=
quote><div><br></div><div>Notice the title of the proposal: "Factored =
cv-qualifier".=C2=A0 I did not say that the construct has no semantics=
, only that it does not allow one to express anything that one could not al=
ready have expressed by qualifying every single data and function member.=
=C2=A0=C2=A0I should have stated clearly that once a cv-qualifier appears i=
n an aggregate heading supplying that same cv-qualifier within that aggrega=
te's body is redundant and hence can be omitted.</div><div><br></div><d=
iv>I could live with it being an attribute.=C2=A0 OTOH the attribute syntax=
exists in part to allow problem-free introduction over time of arbitrary n=
ew identifiers. =C2=A0const (and volatile) are already reserved words so th=
ey do not need to be shielded so.=C2=A0 Finally I find</div><div><br></div>=
</div></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><font face=3D"m=
onospace, monospace">class MyObject const { ... };</font></div></div></div>=
</blockquote><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br=
></div><div>easier to scan than</div><div><br></div></div></div><blockquote=
style=3D"margin:0 0 0 40px;border:none;padding:0px"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div><font face=3D"monospace, monospace">cl=
ass [[const]] MyObject { ... };</font></div></div></div></blockquote><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>(Though=
that may be because I consistently place my cv-qualifiers to the right of =
the type they are qualifying.)</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div st=
yle=3D"word-wrap:break-word"><div><div><span><blockquote type=3D"cite"><div=
><div dir=3D"ltr"><div>=C2=A0It is pure syntactic sugar.=C2=A0 That said it=
allows one to more clearly declare the semantics of an aggregate.</div><di=
v><br></div><div>The overall const-ness of an aggregate is part of its publ=
ic interface.=C2=A0 It allows one to know that after having constructed an =
object and passed it around it remains intact.</div><div><br></div><div>Tod=
ay this overall const-ness property can be ascertained only by an exhaustiv=
e inspection of an aggregate's data members.=C2=A0 Given a style which =
makes all data private and orders an aggregate's body sections { public=
:, protected:, private: } knowledge of this public property is encoded far =
from the rest of the public interface.</div><div><br></div><div>Further, ev=
en after exhaustive inspection (modulo a comment stating that all new data =
members must be declared const) it is unclear to a maintainer whether all e=
xisting data members being const requires new data members also to be const=
..</div></div></div></blockquote><div><br></div></span>Then why not give the=
qualifier semantics and make it enforce it on all data members/methods? Ot=
herwise it seems rather pointless. If the qualifier doesn=E2=80=99t do anyt=
hing then all it=E2=80=99s good for is maybe a compiler warning, and that c=
an be done with an attribute that doesn=E2=80=99t touch any grammar rules.<=
/div></div></div></blockquote><div><br></div><div>I believe that we are &qu=
ot;in violent agreement" (see above).</div><div>=C2=A0</div><blockquot=
e 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-lef=
t:1ex"><div style=3D"word-wrap:break-word"><div><div><br><blockquote type=
=3D"cite"><div><div dir=3D"ltr"><div><br></div><div>/john</div></div><span>=
<font color=3D"#888888"><div><br></div>
-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></div></blockquote></div><span><font color=3D"#888888"><br></=
font></span></div></div><span><font color=3D"#888888">
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1136ac12f98ba3051ac2909c--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 13 Jul 2015 11:34:45 -0700 (PDT)
Raw View
------=_Part_5710_1408109738.1436812485541
Content-Type: multipart/alternative;
boundary="----=_Part_5711_871842854.1436812485549"
------=_Part_5711_871842854.1436812485549
Content-Type: text/plain; charset=UTF-8
On Monday, July 13, 2015 at 7:30:43 AM UTC-7, John Yates wrote:
>
> On Mon, Jul 13, 2015 at 9:43 AM, Miro Knejp <miro....@gmail.com
> <javascript:>> wrote:
>
>>
>> If it has no new semantics it probably should be an attribute.
>>
>
> I could live with it being an attribute. OTOH the attribute syntax exists
> in part to allow problem-free introduction over time of arbitrary new
> identifiers. const (and volatile) are already reserved words so they do
> not need to be shielded so. Finally I find
>
> class MyObject const { ... };
>
>
> easier to scan than
>
> class [[const]] MyObject { ... };
>
>
> (Though that may be because I consistently place my cv-qualifiers to the
> right of the type they are qualifying.)
>
>
>
One reason not to use an attribute is that [[const]] is illegal as an
attribute due to the grammar, even though clang and GCC don't mind (instead
throwing "unknown attribute ignored" warnings). An *attribute-name* is a ::-delimited
sequence of at least one identifier, and const is not an identifier. A
program using [[const]] as an attribute is thus ill-formed in current C++.
const may appear alone in an attribute's parameters, however, as in
[[meow(const)]], if such is permitted by meow.
Melissa
--
---
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_5711_871842854.1436812485549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 13, 2015 at 7:30:43 AM UTC-7, John Yates wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote">On Mon, Jul 13, 2015 at 9:43 AM, Miro Knejp <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">miro....@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div style=3D"word-wrap:break-word"><div><div><span><div><br=
></div></span>If it has no new semantics it probably should be an attribute=
..</div></div></div></blockquote><br><div>I could live with it being an attr=
ibute.=C2=A0 OTOH the attribute syntax exists in part to allow problem-free=
introduction over time of arbitrary new identifiers. =C2=A0const (and vola=
tile) are already reserved words so they do not need to be shielded so.=C2=
=A0 Finally I find</div><div><br></div></div></div><blockquote style=3D"mar=
gin:0 0 0 40px;border:none;padding:0px"><div><div class=3D"gmail_quote"><di=
v><font face=3D"monospace, monospace">class MyObject const { ... };</font><=
/div></div></div></blockquote><div><div class=3D"gmail_quote"><div><br></di=
v><div>easier to scan than</div><div><br></div></div></div><blockquote styl=
e=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div class=3D"gmail_qu=
ote"><div><font face=3D"monospace, monospace">class [[const]] MyObject { ..=
.. };</font></div></div></div></blockquote><div><div class=3D"gmail_quote"><=
div><br></div><div>(Though that may be because I consistently place my cv-q=
ualifiers to the right of the type they are qualifying.)</div><br></div><br=
></div></div></blockquote><div><br>One reason not to use an attribute is th=
at <span style=3D"font-family: courier new,monospace;">[[const]]</span> is =
illegal as an attribute due to the grammar, even though clang and GCC don&#=
39;t mind (instead throwing "unknown attribute ignored" warnings)=
..<span style=3D"font-family: courier new,monospace;"><font face=3D"arial,sa=
ns-serif">=C2=A0 An <i>attribute-name</i> is a <span style=3D"font-family: =
courier new,monospace;">::</span>-delimited sequence of at least one identi=
fier, and <span style=3D"font-family: courier new,monospace;">const</span> =
is not an identifier.=C2=A0 </font></span><span style=3D"font-family: couri=
er new,monospace;"><font face=3D"arial,sans-serif"><span style=3D"font-fami=
ly: courier new,monospace;"><font face=3D"arial,sans-serif">A program using=
<span style=3D"font-family: courier new,monospace;">[[const]]</span> as an=
attribute is thus ill-formed in current C++.</font></span>=C2=A0 <span sty=
le=3D"font-family: courier new,monospace;">const</span> may appear alone in=
an attribute's parameters, however, as in <span style=3D"font-family: =
courier new,monospace;">[[meow(const)]]</span>, if such is permitted by <sp=
an style=3D"font-family: courier new,monospace;">meow</span>.<br><br>Meliss=
a<br></font></span></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5711_871842854.1436812485549--
------=_Part_5710_1408109738.1436812485541--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 13 Jul 2015 11:38:41 -0700
Raw View
On Monday 13 July 2015 11:34:45 Myriachan wrote:
> One reason not to use an attribute is that [[const]] is illegal as an
> attribute due to the grammar, even though clang and GCC don't mind (instead
> throwing "unknown attribute ignored" warnings). An *attribute-name* is a
> ::-delimited sequence of at least one identifier, and const is not an
> identifier. A program using [[const]] as an attribute is thus ill-formed
> in current C++. const may appear alone in an attribute's parameters,
> however, as in [[meow(const)]], if such is permitted by meow.
They probably allow it to catch [[gnu::const]], which is a historical
attribute to indicate const functions (a stricter version of pure functions).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 13 Jul 2015 12:04:58 -0700 (PDT)
Raw View
------=_Part_1261_1121552954.1436814298186
Content-Type: multipart/alternative;
boundary="----=_Part_1262_1033316834.1436814298186"
------=_Part_1262_1033316834.1436814298186
Content-Type: text/plain; charset=UTF-8
On Monday, July 13, 2015 at 11:38:45 AM UTC-7, Thiago Macieira wrote:
>
> On Monday 13 July 2015 11:34:45 Myriachan wrote:
> > One reason not to use an attribute is that [[const]] is illegal as an
> > attribute due to the grammar, even though clang and GCC don't mind
> (instead
> > throwing "unknown attribute ignored" warnings). An *attribute-name* is
> a
> > ::-delimited sequence of at least one identifier, and const is not an
> > identifier. A program using [[const]] as an attribute is thus
> ill-formed
> > in current C++. const may appear alone in an attribute's parameters,
> > however, as in [[meow(const)]], if such is permitted by meow.
>
> They probably allow it to catch [[gnu::const]], which is a historical
> attribute to indicate const functions (a stricter version of pure
> functions).
>
>
I just noticed that I was wrong, but only because one section of the
Standard doesn't contain a cross-reference to another.
2.11 Keywords [lex.key]
>
> The identifiers shown in Table 3 are reserved for use as keywords (that
> is, they are unconditionally treated as keywords in phase 7) except in an
> *attribute-token* (7.6.1).
>
>
So const and volatile are legal attribute identifiers. The only "words"
that are not are the operator replacements and_eq, compl, etc.
I think that if the primary keywords are legal attribute identifiers, the
operator replacements ought to be as well, possibly with the caveat that in
an *attribute-argument-clause*, they have their operator meaning instead of
an identifier. E.g. [[and(3 and 5)]] is parsed as [[and(3 & 5)]], and,
with the presumption that "and" takes a numeric constant-expression
argument, [[and(1)]].
Melissa
--
---
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_1262_1033316834.1436814298186
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, July 13, 2015 at 11:38:45 AM UTC-7, Thiago Macieira wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On Monday 13 July 2015 11:34:45 Myri=
achan wrote:
<br>> One reason not to use an attribute is that [[const]] is illegal as=
an=20
<br>> attribute due to the grammar, even though clang and GCC don't =
mind (instead=20
<br>> throwing "unknown attribute ignored" warnings). =C2=A0An=
*attribute-name* is a
<br>> ::-delimited sequence of at least one identifier, and const is not=
an
<br>> identifier. =C2=A0A program using [[const]] as an attribute is thu=
s ill-formed
<br>> in current C++. const may appear alone in an attribute's param=
eters,
<br>> however, as in [[meow(const)]], if such is permitted by meow.
<br>
<br>They probably allow it to catch [[gnu::const]], which is a historical=
=20
<br>attribute to indicate const functions (a stricter version of pure funct=
ions).
<br><br></blockquote><div><br>I just noticed that I was wrong, but only bec=
ause one section of the Standard doesn't contain a cross-reference to a=
nother.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">2.=
11 Keywords [lex.key]<br></blockquote><blockquote style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" c=
lass=3D"gmail_quote"><br></blockquote><blockquote style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" c=
lass=3D"gmail_quote">The identifiers shown in Table 3 are reserved for use =
as keywords (that is, they are unconditionally treated as keywords in phase=
7) except in an <i>attribute-token</i> (7.6.1).<br></blockquote><blockquot=
e style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, =
204); padding-left: 1ex;" class=3D"gmail_quote"><br></blockquote><br>So <sp=
an style=3D"font-family: courier new,monospace;">const</span> and <span sty=
le=3D"font-family: courier new,monospace;">volatile</span> are legal attrib=
ute identifiers.=C2=A0 The only "words" that are not are the oper=
ator replacements <span style=3D"font-family: courier new,monospace;">and_e=
q</span>, <span style=3D"font-family: courier new,monospace;">compl</span>,=
etc.<br><br>I think that if the primary keywords are legal attribute ident=
ifiers, the operator replacements ought to be as well, possibly with the ca=
veat that in an <i>attribute-argument-clause</i>, they have their operator =
meaning instead of an identifier.=C2=A0 E.g. <span style=3D"font-family: co=
urier new,monospace;">[[and(3 and 5)]]</span> is parsed as <span style=3D"f=
ont-family: courier new,monospace;">[[and(3 & 5)]]</span>, and, with th=
e presumption that "<span style=3D"font-family: courier new,monospace;=
">and</span>" takes a numeric constant-expression argument, <span styl=
e=3D"font-family: courier new,monospace;">[[and(1)]]</span>.<br><br>Melissa=
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1262_1033316834.1436814298186--
------=_Part_1261_1121552954.1436814298186--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 13 Jul 2015 12:39:02 -0700
Raw View
--20cf302ef3cab53281051ac6df20
Content-Type: text/plain; charset=UTF-8
On Mon, Jul 13, 2015 at 12:04 PM, Myriachan <myriachan@gmail.com> wrote:
> On Monday, July 13, 2015 at 11:38:45 AM UTC-7, Thiago Macieira wrote:
>>
>> On Monday 13 July 2015 11:34:45 Myriachan wrote:
>> > One reason not to use an attribute is that [[const]] is illegal as an
>> > attribute due to the grammar, even though clang and GCC don't mind
>> (instead
>> > throwing "unknown attribute ignored" warnings). An *attribute-name* is
>> a
>> > ::-delimited sequence of at least one identifier, and const is not an
>> > identifier. A program using [[const]] as an attribute is thus
>> ill-formed
>> > in current C++. const may appear alone in an attribute's parameters,
>> > however, as in [[meow(const)]], if such is permitted by meow.
>>
>> They probably allow it to catch [[gnu::const]], which is a historical
>> attribute to indicate const functions (a stricter version of pure
>> functions).
>>
>>
> I just noticed that I was wrong, but only because one section of the
> Standard doesn't contain a cross-reference to another.
>
> 2.11 Keywords [lex.key]
>>
>
>> The identifiers shown in Table 3 are reserved for use as keywords (that
>> is, they are unconditionally treated as keywords in phase 7) except in an
>> *attribute-token* (7.6.1).
>>
>
>>
> So const and volatile are legal attribute identifiers. The only "words"
> that are not are the operator replacements and_eq, compl, etc.
>
and_eq and friends are allowed as attribute-tokens too. See
[dcl.attr.grammar]p3: "If a keyword (2.11) or an alternative token (2.5)
that satisfies the syntactic requirements of an identifier (2.10) is
contained in an attribute-token, it is considered an identifier."
I think that if the primary keywords are legal attribute identifiers, the
> operator replacements ought to be as well, possibly with the caveat that in
> an *attribute-argument-clause*, they have their operator meaning instead
> of an identifier. E.g. [[and(3 and 5)]] is parsed as [[and(3 & 5)]],
> and, with the presumption that "and" takes a numeric constant-expression
> argument, [[and(1)]].
>
> Melissa
>
> --
>
> ---
> 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/.
>
--
---
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/.
--20cf302ef3cab53281051ac6df20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jul 13, 2015 at 12:04 PM, Myriachan <span dir=3D"ltr"><<a href=3D"ma=
ilto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><span class=3D"">On Monday, July 13, 2015 at=
11:38:45 AM UTC-7, Thiago Macieira wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Monday 13 Jul=
y 2015 11:34:45 Myriachan wrote:
<br>> One reason not to use an attribute is that [[const]] is illegal as=
an=20
<br>> attribute due to the grammar, even though clang and GCC don't =
mind (instead=20
<br>> throwing "unknown attribute ignored" warnings).=C2=A0 An=
*attribute-name* is a
<br>> ::-delimited sequence of at least one identifier, and const is not=
an
<br>> identifier.=C2=A0 A program using [[const]] as an attribute is thu=
s ill-formed
<br>> in current C++. const may appear alone in an attribute's param=
eters,
<br>> however, as in [[meow(const)]], if such is permitted by meow.
<br>
<br>They probably allow it to catch [[gnu::const]], which is a historical=
=20
<br>attribute to indicate const functions (a stricter version of pure funct=
ions).
<br><br></blockquote></span><div><br>I just noticed that I was wrong, but o=
nly because one section of the Standard doesn't contain a cross-referen=
ce to another.<br><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);p=
adding-left:1ex" class=3D"gmail_quote">2.11 Keywords [lex.key]<br></blockqu=
ote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bor=
der-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" c=
lass=3D"gmail_quote"><br></blockquote><blockquote style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204,204,204);padding-left:1ex" class=3D"gmail_quote">The identifiers show=
n in Table 3 are reserved for use as keywords (that is, they are unconditio=
nally treated as keywords in phase 7) except in an <i>attribute-token</i> (=
7.6.1).<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><br></blockquote><br>So <span styl=
e=3D"font-family:'courier new',monospace">const</span> and <span st=
yle=3D"font-family:'courier new',monospace">volatile</span> are leg=
al attribute identifiers.=C2=A0 The only "words" that are not are=
the operator replacements <span style=3D"font-family:'courier new'=
,monospace">and_eq</span>, <span style=3D"font-family:'courier new'=
,monospace">compl</span>, etc.<br></div></blockquote><div><br></div><div>an=
d_eq and friends are allowed as attribute-tokens too. See [dcl.attr.grammar=
]p3: "If a keyword (2.11) or an alternative token (2.5) that satisfies=
the syntactic requirements of an identifier (2.10) is contained in an attr=
ibute-token, it is considered an identifier."</div><div><br></div><blo=
ckquote 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;paddi=
ng-left:1ex"><div>I think that if the primary keywords are legal attribute =
identifiers, the operator replacements ought to be as well, possibly with t=
he caveat that in an <i>attribute-argument-clause</i>, they have their oper=
ator meaning instead of an identifier.=C2=A0 E.g. <span style=3D"font-famil=
y:'courier new',monospace">[[and(3 and 5)]]</span> is parsed as <sp=
an style=3D"font-family:'courier new',monospace">[[and(3 & 5)]]=
</span>, and, with the presumption that "<span style=3D"font-family:&#=
39;courier new',monospace">and</span>" takes a numeric constant-ex=
pression argument, <span style=3D"font-family:'courier new',monospa=
ce">[[and(1)]]</span>.<br><br>Melissa<br></div><div class=3D""><div class=
=3D"h5">
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf302ef3cab53281051ac6df20--
.