Topic: Attribute double bracket tokens
Author: David Krauss <potswa@gmail.com>
Date: Fri, 4 Jul 2014 08:38:49 +0800
Raw View
--Apple-Mail=_17F39E74-71DF-494C-B9E6-765B61940A7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
The current grammar permits whitespace between the brackets delimiting an a=
ttribute-specifier-seq but categorically disallows other grammar production=
s formed by two consecutive single left bracket tokens.
I wasn't even aware of the restriction until I stumbled across it just now.=
Burying an expression parse rule in =A77.6.1/6 is poor exposition of the g=
rammar.
What is the advantage of doing it this way? Would a [[ token break too much=
existing C++11 code? I get the sense that someone was trying to avoid intr=
oducing tokens, but irregular rules make implementation more difficult, wit=
h inferior results.
Adding [[ would suggest a symmetric ]]. Symmetry is a weak argument, to be =
sure. Nobody in their right mind puts space between the attribute-specifier=
right brackets though, so it might be a good idea to make that ill-formed,=
but no diagnosis required, so as to accommodate implementation. Yet, it's =
easy to let the lexer access a "parsing attributes" flag so as to enable th=
e special ]] token for better QOI.
My suggestion:
1. Add a [[ token to disallow space between double brackets, bringing the g=
rammar in line with actual usage. Only ridiculous code gets broken.=20
2. Disallow the ]] character sequence in balanced-token, NDR. Disallow spac=
e between attribute-delimiting right brackets, NDR. These rules will flag o=
nly obfuscation, at the implementation's convenience. Perhaps add a context=
ual ]] token and merely say that a program that substitutes two single righ=
t brackets is ill-formed, NDR.
3. Remove the restriction on a lambda-expression as the leading subexpressi=
on in an array index.
It's a minor issue to bother with, but it's at a pretty fundamental level, =
and the current spec excludes the best QOI.
--=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=_17F39E74-71DF-494C-B9E6-765B61940A7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">The current grammar pe=
rmits whitespace between the brackets delimiting an attribute-specifier-seq=
but categorically disallows other grammar productions formed by two consec=
utive single left bracket tokens.<div><br></div><div>I wasn’t even aw=
are of the restriction until I stumbled across it just now. Burying an expr=
ession parse rule in =A77.6.1/6 is poor exposition of the grammar.</div><di=
v><br></div><div>What is the advantage of doing it this way? Would a&n=
bsp;<font face=3D"Courier">[[</font> token break too much existin=
g C++11 code? I get the sense that someone was trying to avoid introducing =
tokens, but irregular rules make implementation more difficult, with inferi=
or results.</div><div><br></div><div>Adding <font face=3D"Courier">[[</font=
> would suggest a symmetric <font face=3D"Courier">]]</font>. Symmetry=
is a weak argument, to be sure. Nobody in their right mind puts space betw=
een the <i>attribute-specifier</i> right brackets though, so it might be a =
good idea to make that ill-formed, but no diagnosis required, so as to acco=
mmodate implementation. Yet, it’s easy to let the lexer access a &ldq=
uo;parsing attributes” flag so as to enable the special <font fa=
ce=3D"Courier">]]</font> token for better QOI.</div><div><br></div><di=
v>My suggestion:</div><div><br></div><div>1. Add a <font face=3D"Courier">[=
[</font> token to disallow space between double brackets, bringing the gram=
mar in line with actual usage. Only ridiculous code gets broken. </div=
><div><br></div><div>2. Disallow the <font face=3D"Courier">]]</font> chara=
cter sequence in <i>balanced-token</i>, NDR. Disallow space between attribu=
te-delimiting right brackets, NDR. These rules will flag only obfuscation, =
at the implementation’s convenience. Perhaps add a contextual <f=
ont face=3D"Courier">]]</font> token and merely say that a program that sub=
stitutes two single right brackets is ill-formed, NDR.</div><div><br></div>=
<div>3. Remove the restriction on a lambda-expression as the leading subexp=
ression in an array index.</div><div><br></div><div><br></div><div>It&rsquo=
;s a minor issue to bother with, but it’s at a pretty fundamental lev=
el, and the current spec excludes the best QOI.</div><div><br></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=_17F39E74-71DF-494C-B9E6-765B61940A7C--
.
Author: Myriachan <myriachan@gmail.com>
Date: Sat, 5 Jul 2014 22:59:24 -0700 (PDT)
Raw View
------=_Part_157_5737449.1404626364519
Content-Type: text/plain; charset=UTF-8
On Thursday, July 3, 2014 5:39:50 PM UTC-7, David Krauss wrote:
>
> The current grammar permits whitespace between the brackets delimiting an
> attribute-specifier-seq but categorically disallows other grammar
> productions formed by two consecutive single left bracket tokens.
>
So it is ill-formed to pass a lambda function to an overloaded operator
[]? Weird. Wonder how many compilers enforce that rule. I'll have to try
coliru for a bit =^-^=
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_157_5737449.1404626364519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 3, 2014 5:39:50 PM UTC-7, David Krauss w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word">The current grammar permits whitespace between the brackets deli=
miting an attribute-specifier-seq but categorically disallows other grammar=
productions formed by two consecutive single left bracket tokens.</div></b=
lockquote><div><br>So it is ill-formed to pass a lambda function to an over=
loaded operator []? Weird. Wonder how many compilers enforce th=
at rule. I'll have to try coliru for a bit =3D^-^=3D<br><br>Melissa<b=
r></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 />
------=_Part_157_5737449.1404626364519--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 6 Jul 2014 14:05:56 +0800
Raw View
--Apple-Mail=_1B8210B2-630E-4209-AFD4-18C7A9F14999
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-06, at 1:59 PM, Myriachan <myriachan@gmail.com> wrote:
> On Thursday, July 3, 2014 5:39:50 PM UTC-7, David Krauss wrote:
> The current grammar permits whitespace between the brackets delimiting an attribute-specifier-seq but categorically disallows other grammar productions formed by two consecutive single left bracket tokens.
>
> So it is ill-formed to pass a lambda function to an overloaded operator []? Weird. Wonder how many compilers enforce that rule. I'll have to try coliru for a bit =^-^=
Not quite, it's only unparseable to pass a lambda *expression* as a subscript, unless you add parens around it.
Overloading isn't necessary. I checked with this one-line program and both GCC and Clang complain, don't know about the others:
int i[] = { 1, 2 }, j = i[[]{return 0;}()];
--
---
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/.
--Apple-Mail=_1B8210B2-630E-4209-AFD4-18C7A9F14999
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–06, at 1:59 PM, Myriachan <<a href=3D"mailto:myriachan@gm=
ail.com">myriachan@gmail.com</a>> wrote:</div><br class=3D"Apple-interch=
ange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">On Thursday, July =
3, 2014 5:39:50 PM UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div style=3D"word-wrap:break-word">The current grammar perm=
its whitespace between the brackets delimiting an attribute-specifier-seq b=
ut categorically disallows other grammar productions formed by two consecut=
ive single left bracket tokens.</div></blockquote><div><br>So it is ill-for=
med to pass a lambda function to an overloaded operator []? Weird.&nb=
sp; Wonder how many compilers enforce that rule. I'll have to try col=
iru for a bit =3D^-^=3D<br></div></div></blockquote><div><br></div><div>Not=
quite, it’s only unparseable to pass a lambda *<i>expression</i>*&nb=
sp;as a subscript, unless you add parens around it.</div></div><br><div>Ove=
rloading isn’t necessary. I checked with this one-line program a=
nd both GCC and Clang complain, don’t know about the others:</div><di=
v><br></div><div><font face=3D"Courier">int i[] =3D { 1, 2 }, j =3D i[[]{re=
turn 0;}()];<br></font></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=_1B8210B2-630E-4209-AFD4-18C7A9F14999--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 8 Jul 2014 21:08:32 -0700 (PDT)
Raw View
------=_Part_1767_4415857.1404878912382
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, July 5, 2014 11:06:11 PM UTC-7, David Krauss wrote:
>
> Not quite, it=E2=80=99s only unparseable to pass a lambda **expression** =
as a=20
> subscript, unless you add parens around it.
>
> Overloading isn=E2=80=99t necessary. I checked with this one-line program=
and both=20
> GCC and Clang complain, don=E2=80=99t know about the others:
>
> int i[] =3D { 1, 2 }, j =3D i[[]{return 0;}()];
>
My inexperience made me not realize that you didn't have to put parentheses=
=20
around a lambda function before calling it. Like, I didn't know what the=
=20
grammar was, so I didn't think of it.
As long as you don't have to switch meow[([&] { return this->m_var; })] to=
=20
be meow.operator[]([&] { return this->m_var; }) it sounds like an=20
improvement - it's much less of a hack in the grammar to have a conditional=
=20
token than a really strange parser exception.
Melissa
--=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_1767_4415857.1404878912382
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 5, 2014 11:06:11 PM UTC-7, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:=
break-word"><div>Not quite, it=E2=80=99s only unparseable to pass a lambda =
*<i>expression</i>* as a subscript, unless you add parens around it.</=
div><br><div>Overloading isn=E2=80=99t necessary. I checked with this one-l=
ine program and both GCC and Clang complain, don=E2=80=99t know about =
the others:</div><div><br></div><div><font face=3D"Courier">int i[] =3D { 1=
, 2 }, j =3D i[[]{return 0;}()];<br></font></div></div></blockquote><div><b=
r>My inexperience made me not realize that you didn't have to put parenthes=
es around a lambda function before calling it. Like, I didn't know wh=
at the grammar was, so I didn't think of it.<br><br>As long as you don't ha=
ve to switch meow[([&] { return this->m_var; })] to be meow.operator=
[]([&] { return this->m_var; }) it sounds like an improvement - it's=
much less of a hack in the grammar to have a conditional token than a real=
ly strange parser exception.<br><br>Melissa<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 />
------=_Part_1767_4415857.1404878912382--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 9 Jul 2014 13:31:52 +0800
Raw View
--Apple-Mail=_C1B6267B-3D64-4956-8FA2-37B223D0323D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-09, at 12:08 PM, Myriachan <myriachan@gmail.com> wrote:
> it's much less of a hack in the grammar to have a conditional token than =
a really strange parser exception.
.... especially considering that we already have nearly identical conditiona=
l tokenization cases > > vs. >> and < :: vs. <: :, but no other similar gra=
mmar hacks.
Nevertheless, considering how boring this subject is, I don't really know h=
ow to proceed with this complaint except to try not to forget about it, and=
ask advice when I finally attend an ISO meeting. It's not really a defect =
nor an extension, it's just a minor quality issue.
--=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=_C1B6267B-3D64-4956-8FA2-37B223D0323D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–09, at 12:08 PM, Myriachan <<a href=3D"mailto:myriachan@g=
mail.com">myriachan@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>it's much le=
ss of a hack in the grammar to have a conditional token than a really stran=
ge parser exception.<br></div></div></blockquote><div><br></div><div>&helli=
p; especially considering that we already have nearly identical conditional=
tokenization cases <font face=3D"Courier">> ></font> vs. <font =
face=3D"Courier">>></font> and <font face=3D"Courier">< =
::</font> vs. <font face=3D"Courier"><: :</font>, but no other similar g=
rammar hacks.</div><div><br></div><div>Nevertheless, considering how boring=
this subject is, I don’t really know how to proceed with this compla=
int except to try not to forget about it, and ask advice when I finally att=
end an ISO meeting. It’s not really a defect nor an extension, it&rsq=
uo;s just a minor quality issue.</div><div><br></div></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=_C1B6267B-3D64-4956-8FA2-37B223D0323D--
.