[std-proposals] against P1274R0 add $ to identifier names

[p***@lib.hu]

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.

[m***@gmail.com]

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!

Post by p***@lib.hu
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
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 $
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.

[Gašper Ažman]

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

Stay on the basic keyboard-lingual plane please.

Gašper

Post by m***@gmail.com
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!

Post by p***@lib.hu
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
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 $
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Nicolas Lesser]

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.

Post by Gašper Ažman
To make things worse, some non-us keyboards have the local currency symbol
there.
Stay on the basic keyboard-lingual plane please.
Gašper

Post by m***@gmail.com
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!

Post by p***@lib.hu
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
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 $
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=email&utm_source=footer>
.

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

[Barry Revzin]

Post by Nicolas Lesser
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.

[Corentin]

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_

Post by Nicolas Lesser
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.

Post by Gašper Ažman
To make things worse, some non-us keyboards have the local currency
symbol there.
Stay on the basic keyboard-lingual plane please.
Gašper

Post by m***@gmail.com
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!

Post by p***@lib.hu
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
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 $
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
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
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b6ecf33d-f3e0-474b-8876-34bd023ec9d2%40isocpp.org?utm_medium=email&utm_source=footer>
.

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

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

[Matthew Woehlke]

Post by Corentin
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.)

[Thiago Macieira]

Post by Matthew Woehlke
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

[Nicolas Lesser]

Post by Thiago Macieira

Post by Matthew Woehlke
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.

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

[Matthew Woehlke]

Post by Nicolas Lesser

Post by Thiago Macieira
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...

[Dejan Milosavljevic]

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;

Post by Matthew Woehlke

Post by Nicolas Lesser

Post by Thiago Macieira
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
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
.

[Jonathan Müller]

Post by Corentin
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]]`.

[i***@gmail.com]

Post by Nicolas Lesser
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.

Post by Gašper Ažman
To make things worse, some non-us keyboards have the local currency
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.

[Jim Porter]

Post by Nicolas Lesser
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

[Nicolas Lesser]

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.

Post by Jim Porter

Post by Nicolas Lesser
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
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
.

[Jim Porter]

Post by Nicolas Lesser
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

[Miguel Ojeda]

Post by p***@lib.hu
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

[Justin Bassett]

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 <

Post by p***@lib.hu

Post by p***@lib.hu
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
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
.