debug a reserved keyword (even for enums?)

[user1234]

On Saturday, 11 April 2026 at 09:33:34 UTC, libxmoc wrote:
> On Saturday, 11 April 2026 at 01:38:30 UTC, Jonathan M Davis 
> wrote:
>> [...]
>
> This is exactly the kind of friction that D editions should 
> address.
>
> I've been bitten by this twice recently: once designing a UI 
> system where Align align; was illegal, and again a few months 
> ago with SemVer version. Both times, the trailing underscore 
> workaround felt like unnecessary concessions for perfectly 
> unambiguous code.
>
> The fundamental issue isn't whether non-contextual keywords are 
> easier to parse, it's that D already has a mechanism to 
> disambiguate: the dot operator. loggingLevel.debug, 
> Align.align, and SemVer.version are all unambiguous to both the 
> parser and the reader. The token following a dot is already in 
> a different lexical context.
>
> There's precedent for this in other languages. Rust allows 
> self.as and match.as because keywords after . are unambiguous. 
> Even C#—hardly a radical language—has contextual keywords in 
> specific positions.
>
> The "trailing underscore" convention is a concession that keeps 
> accumulating.
>
> debug_, version_, align_, function_, immutable_... at what 
> point do we acknowledge that the cure (universal keyword 
> reservation) is worse than the disease (contextual parsing 
> complexity)?
>
> Editions exist precisely to make breaking improvements like 
> this possible without fragmenting the ecosystem.
>
> Let's do it.

Other solutions exist. FreePascal allows to use keywords as if 
they are identifier if prefixed with an ampersand (because FPC is 
not from the C-family syntax, FPC "address-grabbing" operator is 
@). This is occasionaly useful for the RTTI system (object 
streaming - serialization).

We could imagine a similar system. For example $<keyword> would 
perfectly works (as experimented in styx-lang, this is never 
ambiguous).