`$identifiers`

Document number:: P4234R2
Date:: 2026-07-15
Audience:: EWG; SG22
Project:: ISO/IEC 14882 Programming Languages — C++, ISO/IEC JTC1/SC22/WG21
Reply-to:: Matthias Wippich <mfwippich@gmail.com>
Co-authors:: Murat Can Çağrı <cancagri.dev@gmail.com>

This paper proposes making $ in identifiers conditionally-supported or supported.

0.1

Revision history

0.1. R2 July 2026

added implementation overview
added other approaches
added opt-out usage analysis
removed "Why not allow $ in identifiers unconditionally?" section, as it is now covered in "Other approaches"
removed wording for option 2, as it is no longer considered
incorporated feedback from SG16

0.2. R1 June 2026

summarized the recent core reflector discussion in a section on preprocessing
updated/added wording for all three options
some minor corrections

0.3. R0 May 2026

Original version of the paper.

1. Introduction

One of the oldest and most widely supported extensions to C++ is allowing $ in identifiers. This feature's origins predate both standard C++ and standard C. As GCC notes in its documentation:

In GNU C, you may normally use dollar signs in identifier names. This is because many traditional C implementations allow such identifiers.

Amongst many other compilers this is supported by MSVC, GCC (going back to at least GCC 1.27!), Clang, EDG (might need opt-in), icx and nvc++ (see Compiler Explorer). Some of these implementations make it configurable, for example GCC and Clang both have -f[no-]dollars-in-identifiers to enable or disable this feature (which defaults to enable).

Attempts to standardize $ in identifiers in some form or another date back to at least 1987. The minutes of the 19th X3J11 meeting ([WG14 N034] page 20) note:

49. $ in Identifiers

Peyton (87-220) requested that we permit $ in identifiers, and make all such identifiers reserved to the implementor.

Straw vote:
5 permit $ in reserved identifiers
lots no

In 1992 it was clarified that supporting use of $ in identifiers as a conforming extension is permissible ([X3J11/91-008] page 56).

May a standard conforming implementation make characters in its character set that are not in the required source character set identifier characters?

Answer: Yes.

In recent years, C has made quite a few changes to what they consider an identifier. The original rules allowed any implementation-defined characters, the revised ones did not (see [WG14 N2836]). To address this, [WG14 N3145] introduced a carve-out to once again allow $ anywhere in identifiers as a conforming extension.

In C++, the situation is slightly different. The C++ standard does not acknowledge $ in identifiers at all. As a result, the use of $ in identifiers pedantically renders your code ill-formed. In practice, however, almost all implementations support it as a non-standard extension, which was a conforming extension until C++26. It effectively became a non-conforming extension through the addition of $ to the basic character set (see [P2558]).

2. Proposed change

To align with C and implementation reality, this paper proposes making the use of $ in identifiers conditionally-supported or supported. Conditionally-supported would not make $ in identifiers portable, but it would at least make them explicitly recognized by the standard when supported by the implementation.

[WG14 N3145] mentions that during discussion it was noted that allowing $ in identifiers is a massive syntactic land-grab. However, due to the popularity of this extension, it seems unrealistic that we can ever use $ for anything that would conflict with $identifiers.

3. Additional Motivation

3.1. Linker and toolchain symbol conventions

3.1.1. Linker conventions

Some embedded toolchains expose identifiers containing $ through linker-defined symbols and custom linker conventions.

One such example is armlink from the ARM MDK toolchain:

Symbols that contain the character sequence $$, and all other external names containing the sequence $$, are names reserved by ARM.

Unfortunately the examples given in armlink's documentation are not valid C++.

oops, none of these are valid identifiers

extern

int

Image$$ER_ZI$$Base; extern

int

Image$$ER_ZI$$Limit; extern

int

Image$$ER_RO$$Base; extern

int

Image$$ER_RO$$Limit; extern

int

Image$$ER_RW$$Base; extern

int

Image$$ER_RW$$Limit;

With GCC and Clang this can also be addressed by explicitly specifying the name used in assembler code (Compiler Explorer)

extern

int

Image_ER_ZI_Base

asm

(

Image$$ER_ZI$$Base

)

;

extern

int

Image_ER_ZI_Limit

asm

(

Image$$ER_ZI$$Limit

)

;

extern

int

Image_ER_RO_Base

asm

(

Image$$ER_RO$$Base

)

;

extern

int

Image_ER_RO_Limit

asm

(

Image$$ER_RW$$Limit

)

;

extern

int

Image_ER_RW_Base

asm

(

Image$$ER_RW$$Base

)

;

extern

int

Image_ER_RW_Limit

asm

(

Image$$ER_RW$$Limit

)

;

However, it seems much cleaner and overall less error-prone (did you notice the typo?) to avoid repetition and instead actually allow such implementations to support dollars in identifiers directly.

Likewise, if you target RISC-V you may have come across __global_pointer$ before (8.5.1 of [RISC-V ELF Specification]). The same argument as before applies - however, in this case it will still result in a reserved identifier due to the double underscore.

3.1.2. Symbol patching

Furthermore, armlink supports $Sub$$ and $Super$$ symbol patterns to allow patching existing definitions. This feature is commonly used for startup hooks, C library retargeting and other situations where an existing symbol cannot be modified. For example, RP2040 MDK headers define the following wrapper macros:

# define WRAPPER_FUNC(__FUNC) $Sub$$##__FUNC

# define REAL_FUNC(__FUNC) $Super$$## __FUNC

As with linker-defined Image$$... symbols, there are still some portability concerns. It does however show that $ containing identifiers are a common part of documented embedded toolchain practice rather than merely accidental parser behavior.

3.2. Stricter Domains

In some domains (such as defense, aerospace and avionics) that deal with safety or mission-critical systems, conformance to the C++ International Standard may be a contractual requirement. For example, the requirements for the [TRITON] project, as specified in NATO IFB-CO-13859-TRITON (Unclassified), state:

5.5.6 TRITON software will be developed with any variations from the languages or specifications given below as "Preferred Languages":

C++ [ISO/IEC 14882]

[T1-R1791] TRITON shall comply with the standards and language specifications given in the Description as the Preferred Languages. Any variations from the languages or specifications shall be agreed with the Purchaser

In such environments, using a compiler extension is not merely an engineering portability concern. It can become a compliance issue. Deviations from the contracted obligations may need to be recorded in project coding guidelines, reviewed by QA, justified to the customer or main contractor, and in some cases handled through contract amendments or formal deviation processes. In such stricter domains, the bureaucracy and paperwork required for such changes can easily take months.

As mentioned before, making the use of $ in identifiers conditionally-supported would not make such identifiers portable, nor would it require every implementation to accept them. However, it would change the status of the construct from an unstandardized implementation extension into a construct explicitly recognized by the C++ Standard, when supported by the implementation.

This distinction is useful for stricter environments. A project could specify that it uses C++ as defined by ISO/IEC 14882, together with the conditionally-supported use of $ in identifiers on implementations that document support for it. This is easier to audit, easier to encode in project guidelines, and easier to justify than relying on undocumented or folklore implementation behavior.

3.3. Additional identifier namespace

3.3.1. Macros

Another somewhat common use is in macro identifiers. GitHub search finds more than 5600 uses in code recognized as C++.

For example consider

#if MSVC

# define $inline_never __declspec(noinline)

# define $inline_always __forceinline

#else

# define $inline_never [[gnu::noinline]]

# define $inline_always [[gnu::always_inline]] inline

#endif

#define $inline(_opt) $inline_##_opt

#define $template template for (auto _ : "")

#define $pi 3

#define $assert(...)

do {

((__VA_ARGS__) ? (void)0 : throw std::runtime_error(#__VA_ARGS__));

} while (false) $inline(always) int

foo

(

int

)

{ $assert(a >

)

;

return

* $pi; } $inline(never) int

bar

(

int

char

)

{ $template {

constexpr

auto

ctx

std

meta

current_function

(

)

;

static

constexpr

auto

[

...

Idx

]

std

make_index_sequence

parameters_of

(

ctx

)

size

(

)

{

}

;

return

(

foo

(

[

variable_of

(

parameters_of

(

ctx

)

[

Idx

]

)

]

)

...

)

;

}

Using $ in any identifiers that survive until the assembler takes over might be problematic with some targets. Since macros are long gone at that point, using dollars in macros is relatively safe. This essentially gives us another identifier namespace that is visually distinct from regular identifiers.

If used consistently only for macros, this has the benefit of making them visually stand out. We can validate consistent use easily by using a custom clang-tidy check (see example implementation).

Not only does this reduce the chances of name collisions, it also helps when surveying code - after all, macros come with sharp edges.

3.3.2. Generated code

In a similar fashion, dollars in identifiers can be useful for generated code.

While there has always been C++ code generators, with the recent adoption of [P2996] and its limited reification features such as define_aggregate, there is an ever increasing need for ways to avoid name collisions stemming from generated/reified code.

As a result of that, it's more than likely that we'll continue to see all sorts of creative mangling/uglification schemes - (conditionally) allowing the use of $ provides another viable alternative.

For example, consider a simple struct to struct of arrays transformation (adopted from the struct to struct of arrays example in [P2996]):

template

typename

size_t

struct

struct_of_arrays_impl

{

struct

impl

;

consteval

{

auto

ctx

std

meta

access_context

current

(

)

;

for

(

std

meta

info

member

nonstatic_data_members_of

(

ctx

)

{

auto

array_type

substitute

(

std

array

{

type_of

(

member

)

std

meta

reflect_constant

(

)

}

)

;

auto

mem_descr

data_member_spec

(

array_type

{

name

identifier_of

(

member

)

}

)

;

new_members

push_back

(

mem_descr

)

;

}

define_aggregate

(

impl

new_members

)

;

}

;

template

typename

size_t

using

struct_of_arrays

struct_of_arrays_impl

impl

;

If we, for some reason, attempt to inherit from this generated type, we might run into collisions.

struct

Particle

{

vec3

position

;

vec3

velocity

;

float

lifetime

;

}

;

template

size_t

struct

Particles

struct_of_arrays

Particle

{

vec3

position

(

size_t

)

const

;

oops, collides with generated position member

vec3

velocity

(

size_t

)

const

;

also collides

float

lifetime

(

size_t

)

const

;

also collides

}

;

While this is arguably a naming issue (that could and probably should be get_position instead), these sorts of problems can generally be avoided by uglifying identifiers in generated code. Conditionally allowing dollars gives users a few more options to make those generated names more unique and less likely to collide with user code.

4. Preprocessing

In a recent core reflector discussion it was noted that "$ in identifiers is conditionally supported" can mean multiple things. Essentially we have 3 options:

Option 1: $ is conditionally a nondigit.
Option 2: $ is always a nondigit, but conditionally supported in identifiers.
Option 3: $ is always a nondigit, but conversion of an identifier preprocessing token to an identifier token in translation phase 6 is conditionally supported if the identifier contains $.

To understand the implications, consider the following code:

#define f(x) #x

#define g(x) f(x)

#define foo bar

(

foo$)

Variant	Option #1	Option #2	Option #3
`$` supported	✅ expands to `"foo$"`	✅ expands to `"foo$"`	✅ expands to `"foo$"`
`$` not supported	✅ expands to `"bar$"`	❌ rejected cannot form an identifier preprocessing token in translation phase 3	✅ expands to `"foo$"`

Of course code such as

int

foo$ =

;

will still be rejected if the implementation cannot support $identifiers, regardless of which option we choose - only the diagnostic changes.

Variant	Option #1	Option #2	Option #3
`$` supported	✅	✅	✅
`$` not supported	❌ rejected lexed as identifier `foo` followed by other preprocessing token `$` e.g. `error: stray '$' in program`	❌ rejected cannot form an identifier preprocessing token in translation phase 3 e.g. `error: identifiers containing '$' are not supported`	❌ rejected cannot convert identifier preprocessing token to identifier token in translation phase 6 e.g. `error: identifiers containing '$' are not supported`

Among the conditional approaches, the authors prefer option 3 over options 1 and 2, as it is the least user-hostile option.

Unlike the other options, this gets us consistent preprocessing behavior independent of the target's capabilities rather than a silent change in meaning or a hard error. This also simplifies tooling such as syntax highlighters greatly as they no longer have to be aware of target capabilities in order to tokenize correctly.

An implementation attempt for option 3 can be found at Clang PR #200614.

5. Other approaches

5.1. Revert the changes to the basic character set

Since making $ in identifiers a non-conforming extension was an unintended consequence of [P2558], another approach would be to simply revert adding $ to the basic character set or explicitly exclude it in [lex.pptoken] paragraph 1.

Both of these approaches would revert the status of this extension to a conforming extension. However, this seems strictly worse than any of the other options - for the reasons outlined in §3.2. Stricter Domains, acknowledging extensions as conditionally supported is preferable to leaving them as unstandardized implementation extensions. Therefore, this paper does not propose such a change.

5.2. Allow `$` in identifiers unconditionally

GCC notes in its documentation:

However, dollar signs in identifiers are not supported on a few target machines, typically because the target assembler does not allow them.

Examples of such targets are RS/6000, AVR, and MMIX.

Despite the existence of GCC target configurations that do not allow dollars in identifiers by default, one could argue that we should simply mandate $ to be valid in identifiers and ask compilers to work around such problematic targets in some way or another. In principle, this should be no different to handling arbitrary Unicode characters in identifiers.

As demonstrated by Clang, some targets excluded by GCC (such as RS/6000) have no fundamental issue with $ in identifiers (see Compiler Explorer). For AVR clang also supports $ in identifiers by default (see Compiler Explorer).

This essentially changes the choice of whether the opt-out or the opt-in is the conforming option. To recap:

Option	Opt-in is conforming	Opt-out is conforming
Status Quo pre-C++26	✅	✅
Status Quo C++26	❌	✅
Allow `$` in identifiers unconditionally	✅	❌

Since almost all compilers support $ in identifiers in C++ mode by default, this would imply next to no changes to implementations if they wish to remain conforming. Due to the ubiquity of this extension, this approach would also match user expectations most closely. For these reasons, and based on the SG16 review, the authors support this option over all other considered ones.

6. Implementation status

In the following table "opt-out behavior" refers to the preprocessing result of a program

#define f(x) #x

#define g(x) f(x)

#define foo bar

(

foo$)

with support for dollars in identifiers disabled (explicitly or implicitly).

Compiler	Default	CLI Option	Opt-Out Behavior
Clang	✅ allowed	`-f[no-]dollars-in-identifiers`	`"bar$"`
GCC	✅ allowed	`-f[no-]dollars-in-identifiers`	`"bar$"`
MSVC	✅ allowed	`/Za` (only opt-out, disables all MS extensions)	`"bar$"`
EDG	❌ not allowed	`--dollar` (only opt-in)	`"bar$"`
nvc++	documented as not allowed tested as allowed	`-optk_allow_dollar_in_id_chars` (only opt-in)	N/A
icx	✅ allowed	`-f[no-]dollars-in-identifiers`	`"bar$"`
AOCC	✅ allowed	`-f[no-]dollars-in-identifiers`	`"bar$"`

With all tested compilers except for NVC++ (which does not seem to have an opt-out), the observed behavior when opting out matches wording option 1. An overview can be found on Compiler Explorer.

7. Opt-out usage

Since most compilers support $ in identifiers by default, we should see lots of use of the opt-out if this extension causes problems for users. However, GitHub code search does not verify this.

7.1. CMake

A search for -fno-dollars-in-identifiers in CMake files yields only 26 results at the time of writing. This includes mostly old forks of eclipse-omr and eclipse-openj9. Both projects have since removed the opt-out upstream (OpenJ9 and OMR), because it caused issues as both commits note:

Apple patches libstdc++v3 with additional support for dtrace. These dtrace symbols use dollar signs identifiers, and are incompatible with the compile option -fno-dollars-in-identifiers.

In particular, several patched headers (e.g. bits/os_defines.h) contain declarations such as:

extern

void

__dtrace_probe$cxa_runtime$cxa_exception_rethrow$v1(void); extern

void

__dtrace_probe$cxa_runtime$cxa_exception_throw$v1$766f6964202a(void *

)

;

These declarations are incompatible with -fno-dollars-in-identifiers.

7.2. Makefiles

A search for -fno-dollars-in-identifiers in Makefiles yields only 187 results at the time of writing. Aside from numerous old forks of OpenJ9 and OMR, many of these results are game decompilation projects (e.g. CLeSeducteur/oot, mzxrules/mm, LLONSIT/Wave-Race-64 and Lrs121/animalforest).

These game decompilation projects appear to share related build infrastructure and might have been generated by the same decompilation tool. It is not entirely clear why that tool added -fno-dollars-in-identifiers to the build options, as none of the inspected projects rely on $ being tokenized separately from an adjacent identifier in any C or C++ translation units.

These projects do however preprocess assembly sources with a C++ preprocessor. GCC and Clang support this with the language mode -x assembler-with-cpp, which has different defaults than the C and C++ language modes. In this mode, $ is not treated as a nondigit by default.

Reliance on this behavior is not limited to game decompilation projects. For example, the Linux kernel uses $rva(1b) in preprocessed assembly sources, where $ must remain separate for the rva macro to be expanded. At the same time, the kernel relies on $ being valid in identifiers in C mode for declarations such as $global$ and $$divI.

The inspected uses therefore provide evidence for preserving assembly-specific preprocessing behavior, but do not demonstrate a need to opt-out of $identifiers in C++ mode.

8. Wording

Make the following changes to the C++ Working Draft. All wording is relative to [N5046], the latest draft at the time of writing.

8.1. Wording Option 1 - conditionally consider `$` a nondigit

Add a new paragraph after [lex.name] paragraph 1

Identifiers [lex.name]
identifier:
    identifier-start
    identifier identifier-continue

identifier-start:
    nondigit
    an element of the translation character set with the Unicode property XID_Start

identifier-continue:
    digit
    nondigit
    an element of the translation character set with the Unicode property XID_Continue

nondigit: one of
    a b c d e f g h i j k l m
    n o p q r s t u v w x y z
    A B C D E F G H I J K L M
    N O P Q R S T U V W X Y Z 
    _ see below

digit: one of
    0 1 2 3 4 5 6 7 8 9
[Note: The character properties XID_Start and XID_Continue are described by UAX #44 of the Unicode Standard. — end note]

1 The program is ill-formed if an identifier does not conform to Normalization Form C as specified in the Unicode Standard.

[Note: Identifiers are case-sensitive. — end note]

[Note: [uaxid] compares the requirements of UAX #31 of the Unicode Standard with the C++ rules for identifiers. — end note]

[Note: In translation phase 4, identifier also includes those preprocessing-tokens ([lex.pptoken]) differentiated as keywords ([lex.key]) in the later translation phase 7 ([lex.token]). — end note]

2 It is implementation-defined whether $ is included in nondigit.

3 The identifiers in Table 4 have a special meaning when appearing in a certain context. [...]

8.2. Wording Option 3 - reject in phase 6

Add $ to nondigit in [lex.name]. Add new paragraph to [lex.token].

Identifiers [lex.name]
identifier:
    identifier-start
    identifier identifier-continue

identifier-start:
    nondigit
    an element of the translation character set with the Unicode property XID_Start

identifier-continue:
    digit
    nondigit
    an element of the translation character set with the Unicode property XID_Continue

nondigit: one of
    a b c d e f g h i j k l m
    n o p q r s t u v w x y z
    A B C D E F G H I J K L M
    N O P Q R S T U V W X Y Z 
    _ $

digit: one of
    0 1 2 3 4 5 6 7 8 9
[Note: The character properties XID_Start and XID_Continue are described by UAX #44 of the Unicode Standard. — end note]

1 The program is ill-formed if an identifier does not conform to Normalization Form C as specified in the Unicode Standard.

[Note: Identifiers are case-sensitive. — end note]

[Note: [uaxid] compares the requirements of UAX #31 of the Unicode Standard with the C++ rules for identifiers. — end note]

[Note: In translation phase 4, identifier also includes those preprocessing-tokens ([lex.pptoken]) differentiated as keywords ([lex.key]) in the later translation phase 7 ([lex.token]). — end note]

2 The identifiers in Table 4 have a special meaning when appearing in a certain context. [...]

Tokens [lex.token]
token:
    identifier
    keyword
    literal
    header-name
    operator-or-punctuator
1 There are six kinds of tokens: identifiers, keywords, literals, header names, operators, and other separators.

2 Identifier tokens that are converted from identifier preprocessing tokens containing $ are conditionally-supported.

8.3. Wording Option 4 - allow unconditionally

Modify nondigit in [lex.name] as follows

Identifiers [lex.name]

identifier:
    identifier-start
    identifier identifier-continue

identifier-start:
    nondigit
    an element of the translation character set with the Unicode property XID_Start

identifier-continue:
    digit
    nondigit
    an element of the translation character set with the Unicode property XID_Continue

nondigit: one of
    a b c d e f g h i j k l m
    n o p q r s t u v w x y z
    A B C D E F G H I J K L M
    N O P Q R S T U V W X Y Z 
    _ $

digit: one of
    0 1 2 3 4 5 6 7 8 9

9. Acknowledgements

Massive thanks to Brian Bi for continued feedback and help with the wording of this paper. Thanks to Jan Schultke for the markup language and document generator used for this paper and thanks to all the other awesome people who gave feedback on this proposal.

10. References

[N5046] Thomas Köppe. Working Draft Programming Languages — C++ 2026-05-12 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/n5046.pdf

[WG14 N3145] $ in Identifiers v2 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3145.pdf

[P2996] Reflection for C++26 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r13.html

[TRITON] NATO TRITON IFB-CO-13859-TRITON https://www.gdaee.mil.gr/wp-content/uploads/2021/09/5_2.pdf

[JSFAVRules] Lockheed Martin. Joint Strike Fighter Air Vehicle C++ Coding Standards for the System Development and Demonstration Program https://www.stroustrup.com/JSF-AV-rules.pdf

[MISRACPP2023] The MISRA Consortium. MISRA C++:2023: Guidelines for the use of C++17 in critical systems https://misra.org.uk/product/misra-cpp2023/

[AUTOSARCPP14] AUTOSAR. Guidelines for the use of the C++14 language in critical and safety-related systems https://www.autosar.org/fileadmin/standards/R17-03_R1.1.0/AP/AUTOSAR_RS_CPP14Guidelines.pdf

[WG14 N2836] Identifier Syntax using Unicode Standard Annex 31 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf

[RISC-V ELF Specification] RISC-V ABIs Specification https://lists.riscv.org/g/tech-psabi/attachment/61/0/riscv-abi.pdf

[P2558] Add @, $, and ` to the basic character set https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2558r2.html

[X3J11/91-008] Defect Report #027 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n289.pdf

[WG14 N034] X3J11 Meeting No. 19 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n034.pdf

$identifiers

R2 July 2026

R1 June 2026

R0 May 2026

Introduction

Proposed change

Additional Motivation

Linker and toolchain symbol conventions

Linker conventions

Symbol patching

Stricter Domains

Additional identifier namespace

Macros

Generated code

Preprocessing

Other approaches

Revert the changes to the basic character set

Allow $ in identifiers unconditionally

Implementation status

Opt-out usage

CMake

Makefiles

Wording

Wording Option 1 - conditionally consider $ a nondigit

Wording Option 3 - reject in phase 6

Wording Option 4 - allow unconditionally

Acknowledgements

References

Revision history

0.1. R2 July 2026

0.2. R1 June 2026

0.3. R0 May 2026

1. Introduction

2. Proposed change

3. Additional Motivation

3.1. Linker and toolchain symbol conventions

3.1.1. Linker conventions

3.1.2. Symbol patching

3.2. Stricter Domains

3.3. Additional identifier namespace

3.3.1. Macros

3.3.2. Generated code

4. Preprocessing

5. Other approaches

5.1. Revert the changes to the basic character set

5.2. Allow $ in identifiers unconditionally

6. Implementation status

7. Opt-out usage

7.1. CMake

7.2. Makefiles

8. Wording

8.1. Wording Option 1 - conditionally consider $ a nondigit

Identifiers [lex.name]

8.2. Wording Option 3 - reject in phase 6

Identifiers [lex.name]

Tokens [lex.token]

8.3. Wording Option 4 - allow unconditionally

Identifiers [lex.name]

9. Acknowledgements

10. References

`$identifiers`

Allow `$` in identifiers unconditionally

Wording Option 1 - conditionally consider `$` a nondigit

5.2. Allow `$` in identifiers unconditionally

8.1. Wording Option 1 - conditionally consider `$` a nondigit