Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
169 lines (149 sloc) 4.79 KB
<pre class="metadata">
Markup Shorthands: markdown yes
Group: WG21
Status: P
Shortname: P1274
Revision: 0
Audience: EWG
Title: Bang For The Buck
Editor: Isabella Muerte,
Date: 2018-07-15
Abstract: We should give C++ programmers the ability to use additional
Abstract: characters in identifiers
!Current Render: <a href="">P1274R0</a>
!Current Source: <a href="">slurps-mad-rips/papers/proposals/</a>
ins {background-color: #CCFFCC; text-decoration: underline;}
del {background-color: #FFCACA; text-decoration: line-through;}
# Revision History # {#changelog}
## Revision 0 ## {#r0}
Initial Release 🎉
# Motivation # {#motivation}
Despite the vast number of characters now alloted to the C++ standard regarding
identifiers, the one character that is continually seen in extensions is the
ASCII character `$`. While some want to permit this as an operator `reflexpr`,
it is the author's opinion that it makes more sense to permit it as an
identifier in functions, namespaces, classes, and variables.
While there are some concerns regarding permitting its use in identifiers,
this paper does layout a solution for vendors who have supported this extension
on some platforms up until now, while also laying a foundation for future
characters that exist on all keyboards but might cause linker issues with
older platforms.
Additionally, this paper seeks to permit adding both the `!` and `?` tokens at
the end of member functions. This would permit calls such as `ptr.reset!()`,
and `vector.empty?()`, which could be used to reduce confusion when a function
might be a modifier vs an observer.
# Design # {#design}
While several vendors have permitted the use of the `$` in the past, it is not
able to be supported on all platforms due to linker requirements. While the C++
standard does not have a true notion of "a linker", there is still the reality
that at the end of the day we need to combine our translation units into
*something*. Because of this, this paper takes a unique route for representing
the `$` in sources. Effectively, we do not add `$` to the basic source
character set. Instead, we permit the preprocessor during the 1st phase of
translation to turn the `$` into its *universal-character-name*, thus rendering
it into the value `\u0024`. Current implementations are then free to mangle the
resulting identifier as though it were a unicode character. For platforms that
have supported `$` as an extension, they are free to generate symbols for both
the unicode and `$` literal character.
Both `!` and `?` are part of the *basic-execution-set* and therefore are being
repurposed for this specific identifier location.
# Wording # {#wording}
All wording is relative to [[N4762]].
Note: Wording for the exact changes to permit **!** and **?** are currently
withheld until the San Diego post mailing to see where they should be placed
exactly within the grammar.
## ! and ? ## {#wording-interrobang}
Insert into 5.10 Identifiers [****]
: *identifier*
:: *identifier-nondigit*
:: *identifier* *identifier-nondigit*
:: *identifier* *digit*
: <ins>*identifier-special*:</ins>
:: <ins>*identifier* *identifier-special-char*</ins>
: <ins>*identifier-special-char*: one of</ins>
:: <ins>**!** **?**</ins>
## $ ## {#wording-buck}
Insert into Table 2 in 5.10 Identifiers [****]
<table class="tg">
You can’t perform that action at this time.