Repository navigation
Using $ prefix for pointer expression terms means they might collide with Solidity identifiers #310
Description
In Solidity, it's valid for an identifier to begin with $, and, as raised in this discussion, solc intends to use user-specified identifiers directly in pointer output, e.g. in region or template names. This means that if a source defines a variable with identifier $wordsize, then this could conflict with the format's own "$wordsize" pointer expression.
In the linked discussion, one option raised is to change this leading prefix for the format's own vocabulary terms. % was my first suggestion, but it is a YAML indicator character, so every operator key and constant would need quotes in the schema sources. The current candidate is ~ (see below).
Other options include:
- Keep
$reserved. Compilers can choose a different naming strategy other than "the exact same identifier"... prefixing_, for instance, or escaping$specifically, etc. - Reserve only the words actually used by the format, rather than everything with a
$prefix. Compilers would still need some kind of escaping mechanism for collisions with these reserved words.
If we do change $, the new choice must be invalid as an identifier prefix in all known languages, and valid+unambiguous in YAML without quotes. ~ meets both (details in comments). Other suggestions are welcome.
Activity
gnidan commentedon Oct 1, 2026
%is out; it's a directive indicator in YAML, so a plain scalar can't start with it.%sumbecomes a parse error without quotes.~is much better:[a-zA-Z$_][a-zA-Z0-9$_]*), Yul and inline assembly ([a-zA-Z_$][a-zA-Z_$0-9.]*), Vyper ([a-zA-Z_]\w*), and Fe ([a-zA-Z_][a-zA-Z0-9_]*, where ~ is its own token).~sum: [1, ~wordsize]and.length: ~thisparse as expected in YAML 1.2 and 1.1. A lone~means null, but this format does not use the sigil here by itself.~as~0, so a tool that addresses a location inside an ethdebug pointer has to write/offset/~0difference. That is minor next to the gains.I suppose there also remains an open question, which is that we don't necessarily need to change
$sum:, etc.; we only need to change$wordsizeand$this, so what's the scope? I lean very strongly on the use of a consistent prefix across the pointer schema for its vocabulary, although keeping the object keys as$would avoid the JSON Pointer problem.Also, timing? This is a breaking change across the board. I'm proposing to do this now and get another draft release of the format out this week (before more people start paying attention to the format, or implementing it.)
cc @cameel @djolertrk @RaoulSchaffranek
gnidan commentedon Oct 2, 2026
(Ah but there is a small downside which is that
~sumand~wordsize, etc. everywhere looks weird as heck. But maybe the format already looks weird, regardless, and we should just go all-in on weird.)djolertrk commentedon Oct 2, 2026
IMO, doing the switch from
$to~works for solc. argotorg/solidity#16990 isn't merged yet, so we'd target the new release directly and drop our_escaping (or as a follow-up PR once it is "draft released"). On scope, either is fine for solc I think. The keyword spellings live in one place in the code. What matters for us is that identifiers can then start with$, so Solidity names can be used as they are.gnidan commentedon Oct 5, 2026
@cameel can you please confirm this? I want to make this switch as soon as possible if that's what we're going to do.
cameel commentedon Oct 8, 2026
Sorry for the late answer. Yes, it seems fine to me.
I mean, I find it a bit unappealing aesthetically, but looks like
@which I proposed in the issue is out (reserved in YAML) so I don't have a better suggestion.I guess you could just not use literal strings for special constants/variables (i.e. require some structure, like
{"$constant": "wordsize"}to make it unambiguous), but if you prefer special strings,~as good a choice as any.