------=_Part_2092_624951069.1539695677209
Content-Type: multipart/alternative;
 boundary="----=_Part_2093_105391218.1539695677209"

------=_Part_2093_105391218.1539695677209
Content-Type: text/plain; charset="UTF-8"


http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html

Proposes to make $ available in identifier names. I could not locate any
justification in the paper, just the author's opinion.

As I see things there are some characters left unused, not part of the
basic set that we (IMO) are accessible everywhere. We could and maybe
should add them to the basic set. $ and @ jumps to mind, possibly others
exist.

When trigraphs were stripped from the language WG21 kinda declared that
"all world is ASCII and the others are out of luck". Following that really
the whole 7-bit ASCII set could be game, but I'd go with a more friendly
way this time, checking EBCDIC and other still used sets. As far as I see $
and @ would not create an availability problem in practice.

On the other side, extending the basic set could hose language extensions.
If someone has tools either running before the compiler or inside it now
can expect some characters not present in the grammar part of source code
so can be safely piched up for extensions.  I heard Apple folks objecting
on $ for some new syntax on that ground. Such concerns are good to consider.

But in any case I would use a character extension to help adding new
operators, punctuators, language syntax. To support the magnitude of new
features we are adding, that might easier to read compared to new
multi-character operators or another overload of existing operators.

For identifiers we have no shortage of characters. I would not extend that
set even if we put away all mangling/linker related potential problems.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f06c38a8-e92d-4c99-ac15-c71e8ecc091a%40isocpp.org.

------=_Part_2093_105391218.1539695677209
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
8/p1274r0.html<br><br>Proposes to make $ available in identifier names. I c=
ould not locate any justification in the paper, just the author&#39;s opini=
on.<br><br>As I see things there are some characters left unused, not part =
of the basic set that we (IMO) are accessible everywhere. We could and mayb=
e should add them to the basic set. $ and @ jumps to mind, possibly others =
exist. <br><br>When trigraphs were stripped from the language WG21 kinda de=
clared that &quot;all world is ASCII and the others are out of luck&quot;. =
Following that really the whole 7-bit ASCII set could be game, but I&#39;d =
go with a more friendly way this time, checking EBCDIC and other still used=
 sets. As far as I see $ and @ would not create an availability problem in =
practice.<br><br>On the other side, extending the basic set could hose lang=
uage extensions. If someone has tools either running before the compiler or=
 inside it now can expect some characters not present in the grammar part o=
f source code so can be safely piched up for extensions.=C2=A0 I heard Appl=
e folks objecting on $ for some new syntax on that ground. Such concerns ar=
e good to consider.<br><br>But in any case I would use a character extensio=
n to help adding new operators, punctuators, language syntax. To support th=
e magnitude of new features we are adding, that might easier to read compar=
ed to new multi-character operators or another overload of existing operato=
rs.<br><br>For identifiers we have no shortage of characters. I would not e=
xtend that set even if we put away all mangling/linker related potential pr=
oblems.<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f06c38a8-e92d-4c99-ac15-c71e8ecc091a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f06c38a8-e92d-4c99-ac15-c71e8ecc091a=
%40isocpp.org</a>.<br />

------=_Part_2093_105391218.1539695677209--

------=_Part_2092_624951069.1539695677209--

.

------=_Part_2106_1523889639.1539700251521
Content-Type: multipart/alternative;
 boundary="----=_Part_2107_1278629117.1539700251522"

------=_Part_2107_1278629117.1539700251522
Content-Type: text/plain; charset="UTF-8"

Absolutely. Not a single motivation was given, not even an example where it
will be "nice". I haven't checked the latest batch of mails, so no wonder I
missed it, but I see this author has submitted whopping 20 papers!


On Tuesday, October 16, 2018 at 4:14:37 PM UTC+3, pa...@lib.hu wrote:
>
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
>
> Proposes to make $ available in identifier names. I could not locate any
> justification in the paper, just the author's opinion.
>
> As I see things there are some characters left unused, not part of the
> basic set that we (IMO) are accessible everywhere. We could and maybe
> should add them to the basic set. $ and @ jumps to mind, possibly others
> exist.
>
> When trigraphs were stripped from the language WG21 kinda declared that
> "all world is ASCII and the others are out of luck". Following that really
> the whole 7-bit ASCII set could be game, but I'd go with a more friendly
> way this time, checking EBCDIC and other still used sets. As far as I see $
> and @ would not create an availability problem in practice.
>
> On the other side, extending the basic set could hose language extensions.
> If someone has tools either running before the compiler or inside it now
> can expect some characters not present in the grammar part of source code
> so can be safely piched up for extensions.  I heard Apple folks objecting
> on $ for some new syntax on that ground. Such concerns are good to consider.
>
> But in any case I would use a character extension to help adding new
> operators, punctuators, language syntax. To support the magnitude of new
> features we are adding, that might easier to read compared to new
> multi-character operators or another overload of existing operators.
>
> For identifiers we have no shortage of characters. I would not extend that
> set even if we put away all mangling/linker related potential problems.
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org.

------=_Part_2107_1278629117.1539700251522
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Absolutely. Not a single motivation was given, not even an=
 example where it will be &quot;nice&quot;. I haven&#39;t checked the lates=
t batch of mails, so no wonder I missed it, but I see this author has submi=
tted whopping 20 papers!<div><br><br>On Tuesday, October 16, 2018 at 4:14:3=
7 PM UTC+3, pa...@lib.hu wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2018/p1274r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1274r0.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNFpvPGoI07y7osHTrDeD-rhO3vfww&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1274r0.htm=
l\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFpvPGoI07y7osHTrDeD-rhO3vfww&#39;=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018=
/<wbr>p1274r0.html</a><br><br>Proposes to make $ available in identifier na=
mes. I could not locate any justification in the paper, just the author&#39=
;s opinion.<br><br>As I see things there are some characters left unused, n=
ot part of the basic set that we (IMO) are accessible everywhere. We could =
and maybe should add them to the basic set. $ and @ jumps to mind, possibly=
 others exist. <br><br>When trigraphs were stripped from the language WG21 =
kinda declared that &quot;all world is ASCII and the others are out of luck=
&quot;. Following that really the whole 7-bit ASCII set could be game, but =
I&#39;d go with a more friendly way this time, checking EBCDIC and other st=
ill used sets. As far as I see $ and @ would not create an availability pro=
blem in practice.<br><br>On the other side, extending the basic set could h=
ose language extensions. If someone has tools either running before the com=
piler or inside it now can expect some characters not present in the gramma=
r part of source code so can be safely piched up for extensions.=C2=A0 I he=
ard Apple folks objecting on $ for some new syntax on that ground. Such con=
cerns are good to consider.<br><br>But in any case I would use a character =
extension to help adding new operators, punctuators, language syntax. To su=
pport the magnitude of new features we are adding, that might easier to rea=
d compared to new multi-character operators or another overload of existing=
 operators.<br><br>For identifiers we have no shortage of characters. I wou=
ld not extend that set even if we put away all mangling/linker related pote=
ntial problems.<br><br></div></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2=
%40isocpp.org</a>.<br />

------=_Part_2107_1278629117.1539700251522--

------=_Part_2106_1523889639.1539700251521--

.

--000000000000fc76c805785a88bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

To make things worse, some non-us keyboards have the local currency symbol
there.

Stay on the basic keyboard-lingual plane please.

Ga=C5=A1per

On Tue, Oct 16, 2018, 15:30 <mihailnajdenov@gmail.com> wrote:

> Absolutely. Not a single motivation was given, not even an example where
> it will be "nice". I haven't checked the latest batch of mails, so no
> wonder I missed it, but I see this author has submitted whopping 20 paper=
s!
>
>
> On Tuesday, October 16, 2018 at 4:14:37 PM UTC+3, pa...@lib.hu wrote:
>>
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
>>
>> Proposes to make $ available in identifier names. I could not locate any
>> justification in the paper, just the author's opinion.
>>
>> As I see things there are some characters left unused, not part of the
>> basic set that we (IMO) are accessible everywhere. We could and maybe
>> should add them to the basic set. $ and @ jumps to mind, possibly others
>> exist.
>>
>> When trigraphs were stripped from the language WG21 kinda declared that
>> "all world is ASCII and the others are out of luck". Following that real=
ly
>> the whole 7-bit ASCII set could be game, but I'd go with a more friendly
>> way this time, checking EBCDIC and other still used sets. As far as I se=
e $
>> and @ would not create an availability problem in practice.
>>
>> On the other side, extending the basic set could hose language
>> extensions. If someone has tools either running before the compiler or
>> inside it now can expect some characters not present in the grammar part=
 of
>> source code so can be safely piched up for extensions.  I heard Apple fo=
lks
>> objecting on $ for some new syntax on that ground. Such concerns are goo=
d
>> to consider.
>>
>> But in any case I would use a character extension to help adding new
>> operators, punctuators, language syntax. To support the magnitude of new
>> features we are adding, that might easier to read compared to new
>> multi-character operators or another overload of existing operators.
>>
>> For identifiers we have no shortage of characters. I would not extend
>> that set even if we put away all mangling/linker related potential probl=
ems.
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e=
0-474b-8876-34bd023ec9d2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3=
e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3=
n5a1g%40mail.gmail.com.

--000000000000fc76c805785a88bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">To make things worse, some non-us keyboards have the loca=
l currency symbol there.<div dir=3D"auto"><br></div><div dir=3D"auto">Stay =
on the basic keyboard-lingual plane please.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Ga=C5=A1per</div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr">On Tue, Oct 16, 2018, 15:30  &lt;<a href=3D"mailto:mihailna=
jdenov@gmail.com">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Absolutely. Not a single motivation=
 was given, not even an example where it will be &quot;nice&quot;. I haven&=
#39;t checked the latest batch of mails, so no wonder I missed it, but I se=
e this author has submitted whopping 20 papers!<div><br><br>On Tuesday, Oct=
ober 16, 2018 at 4:14:37 PM UTC+3, <a href=3D"mailto:pa...@lib.hu" target=
=3D"_blank" rel=3D"noreferrer">pa...@lib.hu</a> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><br><a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2018/p1274r0.html" rel=3D"nofollow noreferrer" t=
arget=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1=
274r0.html</a><br><br>Proposes to make $ available in identifier names. I c=
ould not locate any justification in the paper, just the author&#39;s opini=
on.<br><br>As I see things there are some characters left unused, not part =
of the basic set that we (IMO) are accessible everywhere. We could and mayb=
e should add them to the basic set. $ and @ jumps to mind, possibly others =
exist. <br><br>When trigraphs were stripped from the language WG21 kinda de=
clared that &quot;all world is ASCII and the others are out of luck&quot;. =
Following that really the whole 7-bit ASCII set could be game, but I&#39;d =
go with a more friendly way this time, checking EBCDIC and other still used=
 sets. As far as I see $ and @ would not create an availability problem in =
practice.<br><br>On the other side, extending the basic set could hose lang=
uage extensions. If someone has tools either running before the compiler or=
 inside it now can expect some characters not present in the grammar part o=
f source code so can be safely piched up for extensions.=C2=A0 I heard Appl=
e folks objecting on $ for some new syntax on that ground. Such concerns ar=
e good to consider.<br><br>But in any case I would use a character extensio=
n to help adding new operators, punctuators, language syntax. To support th=
e magnitude of new features we are adding, that might easier to read compar=
ed to new multi-character operators or another overload of existing operato=
rs.<br><br>For identifiers we have no shortage of characters. I would not e=
xtend that set even if we put away all mangling/linker related potential pr=
oblems.<br><br></div></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6=
gdYf0WZwnW3n5a1g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6r6rx=
h67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n5a1g%40mail.gmail.com</a>.<br />

--000000000000fc76c805785a88bf--

.

--0000000000002840be05785a9ad4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I completely agree. The author provides no reason at all to add '$' as
valid identifier character. I'm also pretty sure that no language I know of
supports using that character in identifiers. Same goes for the ! and ?
characters.

Although there is motivation for those last two characters, I really don't
think it's worth it.

On Tue, Oct 16, 2018, 5:52 PM Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.co=
m> wrote:

> To make things worse, some non-us keyboards have the local currency symbo=
l
> there.
>
> Stay on the basic keyboard-lingual plane please.
>
> Ga=C5=A1per
>
> On Tue, Oct 16, 2018, 15:30 <mihailnajdenov@gmail.com> wrote:
>
>> Absolutely. Not a single motivation was given, not even an example where
>> it will be "nice". I haven't checked the latest batch of mails, so no
>> wonder I missed it, but I see this author has submitted whopping 20 pape=
rs!
>>
>>
>> On Tuesday, October 16, 2018 at 4:14:37 PM UTC+3, pa...@lib.hu wrote:
>>>
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
>>>
>>> Proposes to make $ available in identifier names. I could not locate an=
y
>>> justification in the paper, just the author's opinion.
>>>
>>> As I see things there are some characters left unused, not part of the
>>> basic set that we (IMO) are accessible everywhere. We could and maybe
>>> should add them to the basic set. $ and @ jumps to mind, possibly other=
s
>>> exist.
>>>
>>> When trigraphs were stripped from the language WG21 kinda declared that
>>> "all world is ASCII and the others are out of luck". Following that rea=
lly
>>> the whole 7-bit ASCII set could be game, but I'd go with a more friendl=
y
>>> way this time, checking EBCDIC and other still used sets. As far as I s=
ee $
>>> and @ would not create an availability problem in practice.
>>>
>>> On the other side, extending the basic set could hose language
>>> extensions. If someone has tools either running before the compiler or
>>> inside it now can expect some characters not present in the grammar par=
t of
>>> source code so can be safely piched up for extensions.  I heard Apple f=
olks
>>> objecting on $ for some new syntax on that ground. Such concerns are go=
od
>>> to consider.
>>>
>>> But in any case I would use a character extension to help adding new
>>> operators, punctuators, language syntax. To support the magnitude of ne=
w
>>> features we are adding, that might easier to read compared to new
>>> multi-character operators or another overload of existing operators.
>>>
>>> For identifiers we have no shortage of characters. I would not extend
>>> that set even if we put away all mangling/linker related potential prob=
lems.
>>>
>>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3=
e0-474b-8876-34bd023ec9d2%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f=
3e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6r=
6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n5a1g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6=
r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n5a1g%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALmDwq2_GP9omPdmWYX3R-ktsatMHXgCesatvuHevKxJoUS=
jhQ%40mail.gmail.com.

--0000000000002840be05785a9ad4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I completely agree. The author provides no reason at all =
to add &#39;$&#39; as valid identifier character. I&#39;m also pretty sure =
that no language I know of supports using that character in identifiers. Sa=
me goes for the ! and ? characters.<div dir=3D"auto"><br></div><div dir=3D"=
auto">Although there is motivation for those last two characters, I really =
don&#39;t think it&#39;s worth it.</div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr">On Tue, Oct 16, 2018, 5:52 PM Ga=C5=A1per A=C5=BEman &lt=
;<a href=3D"mailto:gasper.azman@gmail.com">gasper.azman@gmail.com</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto">To make thi=
ngs worse, some non-us keyboards have the local currency symbol there.<div =
dir=3D"auto"><br></div><div dir=3D"auto">Stay on the basic keyboard-lingual=
 plane please.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ga=C5=A1p=
er</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 1=
6, 2018, 15:30  &lt;<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"_=
blank" rel=3D"noreferrer">mihailnajdenov@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Absolutely. Not a single mo=
tivation was given, not even an example where it will be &quot;nice&quot;. =
I haven&#39;t checked the latest batch of mails, so no wonder I missed it, =
but I see this author has submitted whopping 20 papers!<div><br><br>On Tues=
day, October 16, 2018 at 4:14:37 PM UTC+3, <a href=3D"mailto:pa...@lib.hu" =
rel=3D"noreferrer noreferrer" target=3D"_blank">pa...@lib.hu</a> wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><a href=3D"http://=
www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html" rel=3D"nofol=
low noreferrer noreferrer" target=3D"_blank">http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2018/p1274r0.html</a><br><br>Proposes to make $ availa=
ble in identifier names. I could not locate any justification in the paper,=
 just the author&#39;s opinion.<br><br>As I see things there are some chara=
cters left unused, not part of the basic set that we (IMO) are accessible e=
verywhere. We could and maybe should add them to the basic set. $ and @ jum=
ps to mind, possibly others exist. <br><br>When trigraphs were stripped fro=
m the language WG21 kinda declared that &quot;all world is ASCII and the ot=
hers are out of luck&quot;. Following that really the whole 7-bit ASCII set=
 could be game, but I&#39;d go with a more friendly way this time, checking=
 EBCDIC and other still used sets. As far as I see $ and @ would not create=
 an availability problem in practice.<br><br>On the other side, extending t=
he basic set could hose language extensions. If someone has tools either ru=
nning before the compiler or inside it now can expect some characters not p=
resent in the grammar part of source code so can be safely piched up for ex=
tensions.=C2=A0 I heard Apple folks objecting on $ for some new syntax on t=
hat ground. Such concerns are good to consider.<br><br>But in any case I wo=
uld use a character extension to help adding new operators, punctuators, la=
nguage syntax. To support the magnitude of new features we are adding, that=
 might easier to read compared to new multi-character operators or another =
overload of existing operators.<br><br>For identifiers we have no shortage =
of characters. I would not extend that set even if we put away all mangling=
/linker related potential problems.<br><br></div></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer" 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" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank" rel=3D"noreferrer">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" rel=3D"noreferrer">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6=
gdYf0WZwnW3n5a1g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" target=3D"_blank" rel=3D"noreferrer">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n=
5a1g%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2_GP9omPdmWYX3R-ktsatMHXgCesat=
vuHevKxJoUSjhQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2_GP9omPdm=
WYX3R-ktsatMHXgCesatvuHevKxJoUSjhQ%40mail.gmail.com</a>.<br />

--0000000000002840be05785a9ad4--

.

------=_Part_1891_112867415.1539711516303
Content-Type: multipart/alternative;
 boundary="----=_Part_1892_1131734946.1539711516303"

------=_Part_1892_1131734946.1539711516303
Content-Type: text/plain; charset="UTF-8"



On Tuesday, October 16, 2018 at 10:56:54 AM UTC-5, Nicolas Lesser wrote:
>
> I completely agree. The author provides no reason at all to add '$' as
> valid identifier character. I'm also pretty sure that no language I know of
> supports using that character in identifiers. Same goes for the ! and ?
> characters.
>

Ruby and Scheme allow both ! and ?, there are probably others.  Rust macros
use !, which isn't really the same thing as having ! as an arbitrary
identifier, but it's also not not the same thing.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3e71abb-4403-44c0-962c-3bccf938731d%40isocpp.org.

------=_Part_1892_1131734946.1539711516303
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 16, 2018 at 10:56:54 AM UTC-5,=
 Nicolas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto">I completely agree. The author provides no reason at all to add &=
#39;$&#39; as valid identifier character. I&#39;m also pretty sure that no =
language I know of supports using that character in identifiers. Same goes =
for the ! and ? characters.</div></blockquote><div><br></div><div>Ruby and =
Scheme allow both ! and ?, there are probably others.=C2=A0 Rust macros use=
 !, which isn&#39;t really the same thing as having ! as an arbitrary ident=
ifier, but it&#39;s also not not the same thing.=C2=A0<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3e71abb-4403-44c0-962c-3bccf938731d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c3e71abb-4403-44c0-962c-3bccf938731d=
%40isocpp.org</a>.<br />

------=_Part_1892_1131734946.1539711516303--

------=_Part_1891_112867415.1539711516303--

.

--00000000000089edba05785c1151
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Both ! and ? might have better future use in the language, as such, I would
rather not allow them in identifiers.  Tokens are not a community to trade
lightly.
A better solution to the stated problem would be to prefix relevant
functions with is_ or has_




On Tue, 16 Oct 2018 at 17:56 Nicolas Lesser <blitzrakete@gmail.com> wrote:

> I completely agree. The author provides no reason at all to add '$' as
> valid identifier character. I'm also pretty sure that no language I know =
of
> supports using that character in identifiers. Same goes for the ! and ?
> characters.
>
> Although there is motivation for those last two characters, I really don'=
t
> think it's worth it.
>
> On Tue, Oct 16, 2018, 5:52 PM Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.=
com> wrote:
>
>> To make things worse, some non-us keyboards have the local currency
>> symbol there.
>>
>> Stay on the basic keyboard-lingual plane please.
>>
>> Ga=C5=A1per
>>
>> On Tue, Oct 16, 2018, 15:30 <mihailnajdenov@gmail.com> wrote:
>>
>>> Absolutely. Not a single motivation was given, not even an example wher=
e
>>> it will be "nice". I haven't checked the latest batch of mails, so no
>>> wonder I missed it, but I see this author has submitted whopping 20 pap=
ers!
>>>
>>>
>>> On Tuesday, October 16, 2018 at 4:14:37 PM UTC+3, pa...@lib.hu wrote:
>>>>
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
>>>>
>>>> Proposes to make $ available in identifier names. I could not locate
>>>> any justification in the paper, just the author's opinion.
>>>>
>>>> As I see things there are some characters left unused, not part of the
>>>> basic set that we (IMO) are accessible everywhere. We could and maybe
>>>> should add them to the basic set. $ and @ jumps to mind, possibly othe=
rs
>>>> exist.
>>>>
>>>> When trigraphs were stripped from the language WG21 kinda declared tha=
t
>>>> "all world is ASCII and the others are out of luck". Following that re=
ally
>>>> the whole 7-bit ASCII set could be game, but I'd go with a more friend=
ly
>>>> way this time, checking EBCDIC and other still used sets. As far as I =
see $
>>>> and @ would not create an availability problem in practice.
>>>>
>>>> On the other side, extending the basic set could hose language
>>>> extensions. If someone has tools either running before the compiler or
>>>> inside it now can expect some characters not present in the grammar pa=
rt of
>>>> source code so can be safely piched up for extensions.  I heard Apple =
folks
>>>> objecting on $ for some new syntax on that ground. Such concerns are g=
ood
>>>> to consider.
>>>>
>>>> But in any case I would use a character extension to help adding new
>>>> operators, punctuators, language syntax. To support the magnitude of n=
ew
>>>> features we are adding, that might easier to read compared to new
>>>> multi-character operators or another overload of existing operators.
>>>>
>>>> For identifiers we have no shortage of characters. I would not extend
>>>> that set even if we put away all mangling/linker related potential pro=
blems.
>>>>
>>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f=
3e0-474b-8876-34bd023ec9d2%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-=
f3e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=3Demail&utm_source=3Dfo=
oter>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6=
r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n5a1g%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV=
6r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n5a1g%40mail.gmail.com?utm_medium=3De=
mail&utm_source=3Dfooter>
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2_GP9=
omPdmWYX3R-ktsatMHXgCesatvuHevKxJoUSjhQ%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq2_GP=
9omPdmWYX3R-ktsatMHXgCesatvuHevKxJoUSjhQ%40mail.gmail.com?utm_medium=3Demai=
l&utm_source=3Dfooter>
> .
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2BOm%2BSjSnLe8d11wgoVmaKR2t-oJ9MyYb8F3tueSMtQ=
mKconuw%40mail.gmail.com.

--00000000000089edba05785c1151
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Both ! and ?=C2=A0might have better future use in the lang=
uage, as such, I would rather not allow them in identifiers.=C2=A0 Tokens a=
re not a community to trade lightly.<div>A better solution to the stated pr=
oblem would be to prefix relevant functions with is_ or has_</div><div><br>=
</div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr">On Tue, 16 Oct 2018 at 17:56 Nicolas Lesser &lt;<a href=3D"m=
ailto:blitzrakete@gmail.com">blitzrakete@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"auto">I completely agree. The au=
thor provides no reason at all to add &#39;$&#39; as valid identifier chara=
cter. I&#39;m also pretty sure that no language I know of supports using th=
at character in identifiers. Same goes for the ! and ? characters.<div dir=
=3D"auto"><br></div><div dir=3D"auto">Although there is motivation for thos=
e last two characters, I really don&#39;t think it&#39;s worth it.</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 16, 2018, 5:=
52 PM Ga=C5=A1per A=C5=BEman &lt;<a href=3D"mailto:gasper.azman@gmail.com" =
target=3D"_blank">gasper.azman@gmail.com</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"auto">To make things worse, some non-us ke=
yboards have the local currency symbol there.<div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Stay on the basic keyboard-lingual plane please.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">Ga=C5=A1per</div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 16, 2018, 15:30  &lt;<a hr=
ef=3D"mailto:mihailnajdenov@gmail.com" rel=3D"noreferrer" target=3D"_blank"=
>mihailnajdenov@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Absolutely. Not a single motivation was given, not e=
ven an example where it will be &quot;nice&quot;. I haven&#39;t checked the=
 latest batch of mails, so no wonder I missed it, but I see this author has=
 submitted whopping 20 papers!<div><br><br>On Tuesday, October 16, 2018 at =
4:14:37 PM UTC+3, <a href=3D"mailto:pa...@lib.hu" rel=3D"noreferrer norefer=
rer" target=3D"_blank">pa...@lib.hu</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><br><a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2018/p1274r0.html" rel=3D"nofollow noreferrer noreferrer=
" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018=
/p1274r0.html</a><br><br>Proposes to make $ available in identifier names. =
I could not locate any justification in the paper, just the author&#39;s op=
inion.<br><br>As I see things there are some characters left unused, not pa=
rt of the basic set that we (IMO) are accessible everywhere. We could and m=
aybe should add them to the basic set. $ and @ jumps to mind, possibly othe=
rs exist. <br><br>When trigraphs were stripped from the language WG21 kinda=
 declared that &quot;all world is ASCII and the others are out of luck&quot=
;. Following that really the whole 7-bit ASCII set could be game, but I&#39=
;d go with a more friendly way this time, checking EBCDIC and other still u=
sed sets. As far as I see $ and @ would not create an availability problem =
in practice.<br><br>On the other side, extending the basic set could hose l=
anguage extensions. If someone has tools either running before the compiler=
 or inside it now can expect some characters not present in the grammar par=
t of source code so can be safely piched up for extensions.=C2=A0 I heard A=
pple folks objecting on $ for some new syntax on that ground. Such concerns=
 are good to consider.<br><br>But in any case I would use a character exten=
sion to help adding new operators, punctuators, language syntax. To support=
 the magnitude of new features we are adding, that might easier to read com=
pared to new multi-character operators or another overload of existing oper=
ators.<br><br>For identifiers we have no shortage of characters. I would no=
t extend that set even if we put away all mangling/linker related potential=
 problems.<br><br></div></blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer noreferrer" 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" rel=3D"noreferrer noreferrer" target=3D"_blank">std-proposals@isocpp.=
org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"noreferrer =
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" rel=3D"nore=
ferrer" 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" rel=3D"noreferrer" target=3D"_blank">std-proposals@isocpp.org</a>.<br=
>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6=
gdYf0WZwnW3n5a1g%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/CAANG%3DkV6r6rxh67F99PKOp04v3ZsRSCjT6gdYf0WZwnW3n=
5a1g%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq2_GP9omPdmWYX3R-ktsatMHXgCesat=
vuHevKxJoUSjhQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfooter"=
 target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/CALmDwq2_GP9omPdmWYX3R-ktsatMHXgCesatvuHevKxJoUSjhQ%40mail.gmail.com</=
a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjSnLe8d11wgoVmaKR2t-oJ9MyY=
b8F3tueSMtQmKconuw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjS=
nLe8d11wgoVmaKR2t-oJ9MyYb8F3tueSMtQmKconuw%40mail.gmail.com</a>.<br />

--00000000000089edba05785c1151--

.

------=_Part_2433_621568549.1539712074996
Content-Type: multipart/alternative;
 boundary="----=_Part_2434_953050007.1539712074996"

------=_Part_2434_953050007.1539712074996
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tuesday, October 16, 2018 at 5:56:54 PM UTC+2, Nicolas Lesser wrote:
>
> I completely agree. The author provides no reason at all to add '$' as=20
> valid identifier character. I'm also pretty sure that no language I know =
of=20
> supports using that character in identifiers. Same goes for the ! and ?=
=20
> characters.
>
> Although there is motivation for those last two characters, I really don'=
t=20
> think it's worth it.
>
> On Tue, Oct 16, 2018, 5:52 PM Ga=C5=A1per A=C5=BEman <gasper...@gmail.com=
=20
> <javascript:>> wrote:
>
>> To make things worse, some non-us keyboards have the local currency=20
>> symbol there.
>>
>> Stay on the basic keyboard-lingual plane please.
>>
>>
One character for one library: https://jquery.com/
Is hard to say that this character have no usage, quite opposite.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c89de9b9-0be5-45d7-bbe4-0db733474ad9%40isocpp.or=
g.

------=_Part_2434_953050007.1539712074996
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 16, 2018 at 5:56:54 PM UTC+2, =
Nicolas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"auto">I completely agree. The author provides no reason at all to add &=
#39;$&#39; as valid identifier character. I&#39;m also pretty sure that no =
language I know of supports using that character in identifiers. Same goes =
for the ! and ? characters.<div dir=3D"auto"><br></div><div dir=3D"auto">Al=
though there is motivation for those last two characters, I really don&#39;=
t think it&#39;s worth it.</div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Tue, Oct 16, 2018, 5:52 PM Ga=C5=A1per A=C5=BEman &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ev-oxRCuBAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">gasper...@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
auto">To make things worse, some non-us keyboards have the local currency s=
ymbol there.<div dir=3D"auto"><br></div><div dir=3D"auto">Stay on the basic=
 keyboard-lingual plane please.</div><br></div></blockquote></div></blockqu=
ote><div><br></div><div>One character for one library: https://jquery.com/<=
/div><div>Is hard to say that this character have no usage, quite opposite.=
<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c89de9b9-0be5-45d7-bbe4-0db733474ad9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c89de9b9-0be5-45d7-bbe4-0db733474ad9=
%40isocpp.org</a>.<br />

------=_Part_2434_953050007.1539712074996--

------=_Part_2433_621568549.1539712074996--

.

On 16/10/2018 13.41, Corentin wrote:
> Both ! and ? might have better future use in the language, as such, I would
> rather not allow them in identifiers.  Tokens are not a community to trade
> lightly.

Right now, something like `if (x.empty?(y))` is an error... not because
`?` can't be used in an identifier, but because `empty` is a function
and must be called, and there is a missing `:`. Allowing `?` in
identifiers thus has some (possibly small) risk of breaking existing
code. Given that, it's hard to see the proposal as being of sufficient
value to merit taking that chance.

(On an unrelated note, I find it... interesting that the author gives a
twitter feed as her only overt contact info.)

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1484cf21-8224-4fb8-457e-8c1e4a3121c2%40gmail.com.

.

On 10/16/2018 8:56 AM, Nicolas Lesser wrote:
> I completely agree. The author provides no reason at all to add '$' as
> valid identifier character. I'm also pretty sure that no language I know
> of supports using that character in identifiers.
Javascript is a big one. The "dollar function", `$()`, is a very common
idiom to define it as a shorthand for `document.getElementById`.
However, I think "$" would be better reserved for an operator; wasn't it
used in one of the reflection proposals?

- Jim

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0f13a054-f0ab-d712-7c21-713578309327%40gmail.com.

.

--000000000000789a6705785ca2bc
Content-Type: text/plain; charset="UTF-8"

Yeah, but it was shot down because apparently a lot of people use $ inside
of auto generated C++ or something like that.

Thanks for giving examples of languages that do use those characters though.

On Tue, Oct 16, 2018 at 8:06 PM Jim Porter <itsjimporter@gmail.com> wrote:

> On 10/16/2018 8:56 AM, Nicolas Lesser wrote:
> > I completely agree. The author provides no reason at all to add '$' as
> > valid identifier character. I'm also pretty sure that no language I know
> > of supports using that character in identifiers.
> Javascript is a big one. The "dollar function", `$()`, is a very common
> idiom to define it as a shorthand for `document.getElementById`.
> However, I think "$" would be better reserved for an operator; wasn't it
> used in one of the reflection proposals?
>
> - Jim
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0f13a054-f0ab-d712-7c21-713578309327%40gmail.com
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0nyzNLmT2e6rDDyXD9CuAxM9494ELKjSjD4UEGL7F0Jg%40mail.gmail.com.

--000000000000789a6705785ca2bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yeah, but it was shot down because apparently a lot of peo=
ple use $ inside of auto generated C++ or something like that.<div><br></di=
v><div>Thanks for giving examples of languages that do use those characters=
 though.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue,=
 Oct 16, 2018 at 8:06 PM Jim Porter &lt;<a href=3D"mailto:itsjimporter@gmai=
l.com">itsjimporter@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On 10/16/2018 8:56 AM, Nicolas Lesser wrote:<br>
&gt; I completely agree. The author provides no reason at all to add &#39;$=
&#39; as <br>
&gt; valid identifier character. I&#39;m also pretty sure that no language =
I know <br>
&gt; of supports using that character in identifiers. <br>
Javascript is a big one. The &quot;dollar function&quot;, `$()`, is a very =
common <br>
idiom to define it as a shorthand for `document.getElementById`. <br>
However, I think &quot;$&quot; would be better reserved for an operator; wa=
sn&#39;t it <br>
used in one of the reflection proposals?<br>
<br>
- Jim<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0f13a054-f0ab-d712-7c21-713578309327%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/0f13a054-f0ab-d712-7c21-713578309327%40=
gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq0nyzNLmT2e6rDDyXD9CuAxM9494ELK=
jSjD4UEGL7F0Jg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq0nyzNLmT2e=
6rDDyXD9CuAxM9494ELKjSjD4UEGL7F0Jg%40mail.gmail.com</a>.<br />

--000000000000789a6705785ca2bc--

.

--00000000000046db8b05785cb53b
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 16, 2018, 19:41 Corentin <corentin.jabot@gmail.com> wrote:

> Both ! and ? might have better future use in the language, as such, I
> would rather not allow them in identifiers.  Tokens are not a community to
> trade lightly.
> A better solution to the stated problem would be to prefix relevant
> functions with is_ or has_
>

Note that accidentally calling `vec.empty()` instead of `vec.clear()` can
already be prevented by using `[[nodiscard]]`.

>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa6mqxa2ywrAu%2BnsKH91d5zXbwgcG-8_ttNNHDmDQaznA%40mail.gmail.com.

--00000000000046db8b05785cb53b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">=
On Tue, Oct 16, 2018, 19:41 Corentin &lt;<a href=3D"mailto:corentin.jabot@g=
mail.com">corentin.jabot@gmail.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">Both ! and ?=C2=A0might have better future =
use in the language, as such, I would rather not allow them in identifiers.=
=C2=A0 Tokens are not a community to trade lightly.<div>A better solution t=
o the stated problem would be to prefix relevant functions with is_ or has_=
</div></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto=
">Note that accidentally calling `vec.empty()` instead of `vec.clear()` can=
 already be prevented by using `[[nodiscard]]`.</div><div class=3D"gmail_qu=
ote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJa6mqxa2ywrAu%2BnsKH91d5zXbwgcG=
-8_ttNNHDmDQaznA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJa6mqxa2y=
wrAu%2BnsKH91d5zXbwgcG-8_ttNNHDmDQaznA%40mail.gmail.com</a>.<br />

--00000000000046db8b05785cb53b--

.

On Tuesday, 16 October 2018 11:00:23 PDT Matthew Woehlke wrote:
> Right now, something like `if (x.empty?(y))` is an error... not because
> `?` can't be used in an identifier, but because `empty` is a function
> and must be called, and there is a missing `:`. Allowing `?` in
> identifiers thus has some (possibly small) risk of breaking existing
> code. Given that, it's hard to see the proposal as being of sufficient
> value to merit taking that chance.

But

 if (empty?(y) : (z))

is valid, even if empty is a function. That would be a constant-true, so the
code would be identical to

 if (y)

but valid nonetheless. If we allowed

 if (empty?(y))

then the parser would need to know that it's not a case of the ternary
operator, so it needs to parse a lot before coming to that conclusion.

In other words, show us a parser implementation.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/10926898.pV5Fg0ApEB%40tjmaciei-mobl1.

.

--000000000000bbd24505785cd9ca
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 16, 2018 at 8:33 PM Thiago Macieira <thiago@macieira.org> wrote:

> On Tuesday, 16 October 2018 11:00:23 PDT Matthew Woehlke wrote:
> > Right now, something like `if (x.empty?(y))` is an error... not because
> > `?` can't be used in an identifier, but because `empty` is a function
> > and must be called, and there is a missing `:`. Allowing `?` in
> > identifiers thus has some (possibly small) risk of breaking existing
> > code. Given that, it's hard to see the proposal as being of sufficient
> > value to merit taking that chance.
>
> But
>
>         if (empty?(y) : (z))
>
> is valid, even if empty is a function. That would be a constant-true, so
> the
> code would be identical to
>
>         if (y)
>
> but valid nonetheless. If we allowed
>
>         if (empty?(y))
>
> then the parser would need to know that it's not a case of the ternary
> operator, so it needs to parse a lot before coming to that conclusion.
>

Not really. There is still the "max-munch" rule. Which is why that would
break a bit of code. Your above snippet would be ill-formed with the
change, as there is a colon without condition operator.


>
> In other words, show us a parser implementation.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/10926898.pV5Fg0ApEB%40tjmaciei-mobl1
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3a3Qo2YkQ_0miPqMj6Lx0ck9E_0H%2BA_xTh8fbfF1KZFg%40mail.gmail.com.

--000000000000bbd24505785cd9ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Oct 16=
, 2018 at 8:33 PM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Tuesday, 16 October 2018 11:00:23 PDT Matthew Woehlke wrote:<br>
&gt; Right now, something like `if (x.empty?(y))` is an error... not becaus=
e<br>
&gt; `?` can&#39;t be used in an identifier, but because `empty` is a funct=
ion<br>
&gt; and must be called, and there is a missing `:`. Allowing `?` in<br>
&gt; identifiers thus has some (possibly small) risk of breaking existing<b=
r>
&gt; code. Given that, it&#39;s hard to see the proposal as being of suffic=
ient<br>
&gt; value to merit taking that chance.<br>
<br>
But <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (empty?(y) : (z))<br>
<br>
is valid, even if empty is a function. That would be a constant-true, so th=
e <br>
code would be identical to<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (y)<br>
<br>
but valid nonetheless. If we allowed<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (empty?(y))<br>
<br>
then the parser would need to know that it&#39;s not a case of the ternary =
<br>
operator, so it needs to parse a lot before coming to that conclusion.<br><=
/blockquote><div><br></div><div>Not really. There is still the &quot;max-mu=
nch&quot; rule. Which is why that would break a bit of code. Your above sni=
ppet would be ill-formed with the change, as there is a colon without condi=
tion operator.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In other words, show us a parser implementation.<br>
<br>
-- <br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<br>
<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/10926898.pV5Fg0ApEB%40tjmaciei-mobl1"=
 rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/10926898.pV5Fg0ApEB%40tjmaciei-mobl1</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq3a3Qo2YkQ_0miPqMj6Lx0ck9E_0H%2=
BA_xTh8fbfF1KZFg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3a3Qo2Yk=
Q_0miPqMj6Lx0ck9E_0H%2BA_xTh8fbfF1KZFg%40mail.gmail.com</a>.<br />

--000000000000bbd24505785cd9ca--

.

On 16/10/2018 14.32, Nicolas Lesser wrote:
> On Tue, Oct 16, 2018 at 8:33 PM Thiago Macieira wrote:
>> If we allowed
>>
>>         if (empty?(y))
>>
>> then the parser would need to know that it's not a case of the ternary
>> operator, so it needs to parse a lot before coming to that conclusion.
>
> Not really. There is still the "max-munch" rule. Which is why that would
> break a bit of code. Your above snippet would be ill-formed with the
> change, as there is a colon without condition operator.

If you're saying (as I think you are) that keeping the grammar sane
would mean that an existing identifier followed by `?` with no
intervening whitespace would, under the proposal, include the `?` as
part of the identifier, I think that's a clear non-starter. I'd be
surprised if there isn't a non-trivial amount of existing code that
would be broken by such a change.

Something else that just occurred to me... at least in the absence of
non-ASCII characters, C++ identifiers all match /\w+/. Changing that
could have interesting ramifications...

--
Matthew

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/341708ed-e98b-1744-fbdb-5b1036838323%40gmail.com.

.

--00000000000065c3da057867eb56
Content-Type: text/plain; charset="UTF-8"

Yacc( https://en.wikipedia.org/wiki/Yacc ) use that symbol.

I do not like to see $ in C++.

Nicolas Lesser >>  Yeah, but itwas shot down because apparently a lot of
people use $ inside of auto generated C++ or something like that
std::cout << true << std::endl;

On Tue, Oct 16, 2018 at 8:48 PM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 16/10/2018 14.32, Nicolas Lesser wrote:
> > On Tue, Oct 16, 2018 at 8:33 PM Thiago Macieira wrote:
> >> If we allowed
> >>
> >>         if (empty?(y))
> >>
> >> then the parser would need to know that it's not a case of the ternary
> >> operator, so it needs to parse a lot before coming to that conclusion.
> >
> > Not really. There is still the "max-munch" rule. Which is why that would
> > break a bit of code. Your above snippet would be ill-formed with the
> > change, as there is a colon without condition operator.
>
> If you're saying (as I think you are) that keeping the grammar sane
> would mean that an existing identifier followed by `?` with no
> intervening whitespace would, under the proposal, include the `?` as
> part of the identifier, I think that's a clear non-starter. I'd be
> surprised if there isn't a non-trivial amount of existing code that
> would be broken by such a change.
>
> Something else that just occurred to me... at least in the absence of
> non-ASCII characters, C++ identifiers all match /\w+/. Changing that
> could have interesting ramifications...
>
> --
> Matthew
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/341708ed-e98b-1744-fbdb-5b1036838323%40gmail.com
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwYXdWu1EfYxBmkxbN%3Dn-3WpWqqWx0ApR9DNdgQky-NFA%40mail.gmail.com.

--00000000000065c3da057867eb56
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Yacc( <=
a href=3D"https://en.wikipedia.org/wiki/Yacc">https://en.wikipedia.org/wiki=
/Yacc</a> ) use that symbol.</div><div dir=3D"ltr"><br></div><div>I do not =
like to see $=C2=A0in C++.</div><div><br></div><div>Nicolas Lesser &gt;&gt;=
 =C2=A0Yeah, but itwas shot down because apparently a lot of people use $ i=
nside of auto generated C++ or something like that</div><div><font face=3D"=
monospace,monospace">std::cout &lt;&lt; true &lt;&lt; std::endl;</font><br>=
</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Tue, Oct 16, 2018 at 8:48 PM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke=
..floss@gmail.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">On 16/10/2018 14.32, Nicolas Lesser wrote:<br>
&gt; On Tue, Oct 16, 2018 at 8:33 PM Thiago Macieira wrote:<br>
&gt;&gt; If we allowed<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (empty?(y))<br>
&gt;&gt;<br>
&gt;&gt; then the parser would need to know that it&#39;s not a case of the=
 ternary<br>
&gt;&gt; operator, so it needs to parse a lot before coming to that conclus=
ion.<br>
&gt; <br>
&gt; Not really. There is still the &quot;max-munch&quot; rule. Which is wh=
y that would<br>
&gt; break a bit of code. Your above snippet would be ill-formed with the<b=
r>
&gt; change, as there is a colon without condition operator.<br>
<br>
If you&#39;re saying (as I think you are) that keeping the grammar sane<br>
would mean that an existing identifier followed by `?` with no<br>
intervening whitespace would, under the proposal, include the `?` as<br>
part of the identifier, I think that&#39;s a clear non-starter. I&#39;d be<=
br>
surprised if there isn&#39;t a non-trivial amount of existing code that<br>
would be broken by such a change.<br>
<br>
Something else that just occurred to me... at least in the absence of<br>
non-ASCII characters, C++ identifiers all match /\w+/. Changing that<br>
could have interesting ramifications...<br>
<br>
-- <br>
Matthew<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/341708ed-e98b-1744-fbdb-5b1036838323%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/341708ed-e98b-1744-fbdb-5b1036838323%40=
gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEfefmwYXdWu1EfYxBmkxbN%3Dn-3WpWqqWx=
0ApR9DNdgQky-NFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmwYXdWu1E=
fYxBmkxbN%3Dn-3WpWqqWx0ApR9DNdgQky-NFA%40mail.gmail.com</a>.<br />

--00000000000065c3da057867eb56--

.

On 10/16/2018 11:17 AM, Nicolas Lesser wrote:
> Yeah, but it was shot down because apparently a lot of people use $
> inside of auto generated C++ or something like that.

Yeah, I seem to recall something of that sort, but I can't find the old
thread.

Maybe it's not worth the effort of writing a paper about it, but I
wonder if it would make sense to *explicitly* reserve "$" for other
languages/tools/etc that sit on top of C++. That would give those tools
a bit more certainty and sort of close the book on whether "$" is
allowed for C++.

- Jim

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/83f995fa-f3a1-cad9-19eb-3b852e4ee9ab%40gmail.com.

.

On Tue, Oct 16, 2018 at 3:14 PM <pasa@lib.hu> wrote:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
>
> For identifiers we have no shortage of characters. I would not extend that set even if we put away all mangling/linker related potential problems.

Agreed. Special characters should be reserved for new
syntax/operators/... and, even then, only add them if there is
*really* a need for them.

In my personal opinion, I prefer languages with fewer symbols rather
than more, e.g. I actually like using the keyword-forms not/and/or if
a project allows for it.

Cheers,
Miguel

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kLiCOHVtSFYH0h6ApE5QGyNWUnRpshpcnj-krJk-PRBg%40mail.gmail.com.

.

--00000000000049839c05788807fd
Content-Type: text/plain; charset="UTF-8"

I saw a lot of arguments against this, but I think that this proposal is
being dismissed too quickly. It's not as if adding $ as a legal character
in an identifier is anything new. This proposal would be standardizing
existing practice ( https://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html ),
not creating anything out of nothing. We know that the $ character is
already used in identifiers in autogenerated code. Assigning a meaning
other than as a legal character in an identifier would break existing code.

On Thu, Oct 18, 2018 at 4:50 AM Miguel Ojeda <
miguel.ojeda.sandonis@gmail.com> wrote:

> On Tue, Oct 16, 2018 at 3:14 PM <pasa@lib.hu> wrote:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1274r0.html
> >
> > For identifiers we have no shortage of characters. I would not extend
> that set even if we put away all mangling/linker related potential problems.
>
> Agreed. Special characters should be reserved for new
> syntax/operators/... and, even then, only add them if there is
> *really* a need for them.
>
> In my personal opinion, I prefer languages with fewer symbols rather
> than more, e.g. I actually like using the keyword-forms not/and/or if
> a project allows for it.
>
> Cheers,
> Miguel
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kLiCOHVtSFYH0h6ApE5QGyNWUnRpshpcnj-krJk-PRBg%40mail.gmail.com
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5dLoZYatr1GfWWg%2Bu2DmCy9yuWays1YgpjHJC4cTYse4w%40mail.gmail.com.

--00000000000049839c05788807fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">I saw a lot of arguments against this, bu=
t I think that this proposal is being dismissed too quickly. It&#39;s not a=
s if adding $ as a legal character in an identifier is anything new. This p=
roposal would be standardizing existing practice (=C2=A0<a href=3D"https://=
gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html">https://gcc.gnu.org/onlinedoc=
s/gcc/Dollar-Signs.html</a>=C2=A0), not creating anything out of nothing. W=
e know that the $ character is already used in identifiers in autogenerated=
 code. Assigning a meaning other than as a legal character in an identifier=
 would break existing code.<br></div></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr">On Thu, Oct 18, 2018 at 4:50 AM Miguel Ojeda &lt;<a href=3D=
"mailto:miguel.ojeda.sandonis@gmail.com">miguel.ojeda.sandonis@gmail.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 16, 2018 a=
t 3:14 PM &lt;<a href=3D"mailto:pasa@lib.hu" target=3D"_blank">pasa@lib.hu<=
/a>&gt; wrote:<br>
&gt;<br>
&gt; <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p12=
74r0.html" rel=3D"noreferrer" target=3D"_blank">http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2018/p1274r0.html</a><br>
&gt;<br>
&gt; For identifiers we have no shortage of characters. I would not extend =
that set even if we put away all mangling/linker related potential problems=
..<br>
<br>
Agreed. Special characters should be reserved for new<br>
syntax/operators/... and, even then, only add them if there is<br>
*really* a need for them.<br>
<br>
In my personal opinion, I prefer languages with fewer symbols rather<br>
than more, e.g. I actually like using the keyword-forms not/and/or if<br>
a project allows for it.<br>
<br>
Cheers,<br>
Miguel<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANiq72kLiCOHVtSFYH0h6ApE5QGyNWUnRpsh=
pcnj-krJk-PRBg%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kLiCOHVtSFYH=
0h6ApE5QGyNWUnRpshpcnj-krJk-PRBg%40mail.gmail.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPuuy5dLoZYatr1GfWWg%2Bu2DmCy9yuWays=
1YgpjHJC4cTYse4w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5dLoZYatr=
1GfWWg%2Bu2DmCy9yuWays1YgpjHJC4cTYse4w%40mail.gmail.com</a>.<br />

--00000000000049839c05788807fd--

.