www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - debug a reserved keyword (even for enums?)

reply Katastic <ckatko gmail.com> writes:
Hello all, it's been awhile. I have a question. Does it make 
'sense' that debug is a reserved keyword even when its inside an 
enum?

```D
enum loggingLevel {
	none = 0,
	debug, // Error: found `debug` when expecting `identifier`
	info,
	warning,
	error
}
```

Is there anywhere where that would actually clash?
```D
void myFunction(loggingLevel l);
myFunction(loggingLevel.debug);

with(loggingLevel){
myFunction(debug);
}
```

Is 'debug' used anywhere outside of version() statements? Would 
it explode templates or something?

Thanks,
Apr 10
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, April 10, 2026 4:37:54 PM Mountain Daylight Time Katastic via
Digitalmars-d wrote:

 Hello all, it's been awhile. I have a question. Does it make
 'sense' that debug is a reserved keyword even when its inside an
 enum?

 ```D
 enum loggingLevel {
   none = 0,
   debug, // Error: found `debug` when expecting `identifier`
   info,
   warning,
   error
 }
 ```

 Is there anywhere where that would actually clash?
 ```D
 void myFunction(loggingLevel l);
 myFunction(loggingLevel.debug);

 with(loggingLevel){
 myFunction(debug);
 }
 ```

 Is 'debug' used anywhere outside of version() statements? Would
 it explode templates or something?


As a general rule, keywords in D are keywords no matter where they are. They
are not contextual. As such, you cannot use them anywhere other than where
the language uses that word. There are of course downsides to that approach,
but it's simpler to process than contextual keywords, and it tends to work
better with stuff like error messages (since the keyword then is essentially
an anchor point in the grammar instead of the compiler needing to figure
which context you're trying to use the keyword in when the context isn't
well-formed due to typos or whatnot).

Obviously, that's annoying when you have a situation where a keyword is the
best identfier, but you can't use it, because it's a keyword. However, the
solution that's generally used in D (and given in the official style guide)
is that when you need to use a keyword as an identifier, you apppend an
underscore to it:

https://dlang.org/dstyle.html#naming_keywords

So, you'd have LoggingLevel.debug_ rather than LoggingLevel.debug.

A prime example of where this comes up in the standard library is with
std.traits.FunctionAttribute:

https://dlang.org/phobos/std_traits.html#.FunctionAttribute

The enum literally needs to list a bunch of keywords as its values, and
that's not legal, so trailing underscores have been added to those keywords.

- Jonathan M Davis
Apr 10
next sibling parent reply libxmoc <libxmoc gmail.com> writes:
On Saturday, 11 April 2026 at 01:38:30 UTC, Jonathan M Davis 
wrote:

 On Friday, April 10, 2026 4:37:54 PM Mountain Daylight Time 
 Katastic via Digitalmars-d wrote:

 Hello all, it's been awhile. I have a question. Does it make 
 'sense' that debug is a reserved keyword even when its inside 
 an enum?

 ```D
 enum loggingLevel {
   none = 0,
   debug, // Error: found `debug` when expecting `identifier`
   info,
   warning,
   error
 }
 ```

 Is there anywhere where that would actually clash?
 ```D
 void myFunction(loggingLevel l);
 myFunction(loggingLevel.debug);

 with(loggingLevel){
 myFunction(debug);
 }
 ```

 Is 'debug' used anywhere outside of version() statements? Would
 it explode templates or something?


 As a general rule, keywords in D are keywords no matter where 
 they are. They are not contextual. As such, you cannot use them 
 anywhere other than where the language uses that word. There 
 are of course downsides to that approach, but it's simpler to 
 process than contextual keywords, and it tends to work better 
 with stuff like error messages (since the keyword then is 
 essentially an anchor point in the grammar instead of the 
 compiler needing to figure which context you're trying to use 
 the keyword in when the context isn't well-formed due to typos 
 or whatnot).

 Obviously, that's annoying when you have a situation where a 
 keyword is the best identfier, but you can't use it, because 
 it's a keyword. However, the solution that's generally used in 
 D (and given in the official style guide) is that when you need 
 to use a keyword as an identifier, you apppend an underscore to 
 it:

 https://dlang.org/dstyle.html#naming_keywords

 So, you'd have LoggingLevel.debug_ rather than 
 LoggingLevel.debug.

 A prime example of where this comes up in the standard library 
 is with std.traits.FunctionAttribute:

 https://dlang.org/phobos/std_traits.html#.FunctionAttribute

 The enum literally needs to list a bunch of keywords as its 
 values, and that's not legal, so trailing underscores have been 
 added to those keywords.

 - Jonathan M Davis


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. 

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.
Apr 11
next sibling parent reply user1234 <user1234 12.de> writes:
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. 

 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).
Apr 11
next sibling parent Kagamin <spam here.lot> writes:
On Saturday, 11 April 2026 at 15:53:10 UTC, user1234 wrote:

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


I think, this used to work and $ was a contextually defined 
identifier, not a sigil. On the other hand, it's not much 

pointless to me.
Apr 11
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
English is a very rich language with a million+ words in it. D has 110
keywords, 
which admittedly is a little large.

But fortunately, there are many synonyms for 'align':

https://www.thesaurus.com/browse/align

There are also foreign words available, which can make your code more fun: 
"uitlijnen" is the Dutch word for "align". Or the Klingon word "nagh". If you 
prefer Elvish: "Harya".
Apr 12
prev sibling next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Saturday, 11 April 2026 at 09:33:34 UTC, libxmoc wrote:

 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. 

 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.


Breaking things just to be able to use `align` or `debug` as a 
variable or enum name is not worth it. The solution: find better 
names.

- align: alignment
- debug: debugMode

No language change needed and is backwards compatible. Can't 
comment about contextual keywords.
Apr 11
next sibling parent reply libxmoc <libxmoc gmail.com> writes:
On Saturday, 11 April 2026 at 23:27:14 UTC, Kapendev wrote:

 On Saturday, 11 April 2026 at 09:33:34 UTC, libxmoc wrote:

 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. 

 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.


 Breaking things just to be able to use `align` or `debug` as a 
 variable or enum name is not worth it. The solution: find 
 better names.

 - align: alignment
 - debug: debugMode

 No language change needed and is backwards compatible. Can't 
 comment about contextual keywords.


You are asking me for a concession, again. This is the whole 
point.

Sure, I can rename `align` to `alignment` and `debug` to 
`debugMode`. But that's not the real win here. The real win is we 
don't get stuck with more `__keywords` down the road, and we give 
back control and _choice_ back to the user.

Look at `__gshared`. It's ugly. Now look at `__traits`, 
`__vector`, `__parameters`. D already has this pattern of double 
underscore escapes because new features can't use clean names 
without breaking stuff. And it's only going to get worse. What 
happens when we want `async`? Every one of those is a common 
identifier in real code.

Deserializing XML with an `align` field for your UI? Oh too 
badn,you have to hack your serializer to make an exception. Or 
rename the field in your D struct to `alignment_` and map it 
manually. Or tell your API team to change their schema because D 
can't handle a common word..

Same with JSON from some external service that uses `version`. Or 
a database column named `debug`. You are now fighting every data 
format, config file, and third party API that happens to use a D 
keyword.

I hit this with a CSS parser, `align` is everywhere in CSS. I hit 
it with a package manager, `version` is in every manifest. Every 
time it's "oh, just work around it"

But these workarounds satck up. They leak into serialization 
logic, binding generators, ORMs etc..


People work around this mess constantly, it's friction. And every 
time someone proposes a new feature, the first question is "what 
keyword can we use that won't break the world?" That's backwards.

Other languages solved this.
Apr 12
next sibling parent Lurker <mrai outlook.com> writes:
On Sunday, 12 April 2026 at 07:27:21 UTC, libxmoc wrote:

 Other languages solved this.


AI will solve this, programming languages which will incorporate 
AI in their core will get advantage so in this way keywords will 
don't be need anymore, context will matter more.

Barely unless we are talking about very good 
programmer/mathematician write new Algo daily, AI can write 
better code based on a lot of samples online. So programming is 
turning into a day by day trade where everyone will be able to 
write an app by context, and programmer will go to this route as 
well.

Now back do your problem, if you were vibe coding you wouldn't 
have this problem with most avg AI out there.
Apr 12
prev sibling next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 12 April 2026 at 07:27:21 UTC, libxmoc wrote:

 Same with JSON from some external service that uses `version`. 
 Or a database column named `debug`. You are now fighting every 
 data format, config file, and third party API that happens to 
 use a D keyword.

 I hit this with a CSS parser, `align` is everywhere in CSS. I 
 hit it with a package manager, `version` is in every manifest. 
 Every time it's "oh, just work around it"
antl
 But these workarounds satck up. They leak into serialization 
 logic, binding generators, ORMs etc..


 People work around this mess constantly, it's friction. And 
 every time someone proposes a new feature, the first question 
 is "what keyword can we use that won't break the world?" That's 
 backwards.

 Other languages solved this.


I get it can be annoying, but we have to keep in mind what D is 
right now. Other languages can do things differently because they 
have a different base to work on. D has a base similar to C in 
terms of keywords. It's that kind of language. I don't think it's 
that weird to say that you need to find a different solution in 
language X, Y and Z.


 Think different - Aristotle
Apr 12
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Sunday, 12 April 2026 at 07:27:21 UTC, libxmoc wrote:

 Deserializing XML with an `align` field for your UI? Oh too 
 badn,you have to hack your serializer to make an exception. Or 
 rename the field in your D struct to `alignment_` and map it 
 manually. Or tell your API team to change their schema because 
 D can't handle a common word..


You describe "what is schema?" serialization. It's possible only 
in dynamically typed languages. In statically typed languages 
schema is always present and thus is customizable. Some 
serializers normalize naming conventions.


 I hit this with a CSS parser, `align` is everywhere in CSS. I 
 hit it with a package manager, `version` is in every manifest. 
 Every time it's "oh, just work around it"


Last I checked CSS used kebab case, so you can't naively parse it 
without normalization of naming conventions at all.
Apr 12
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2026 12:27 AM, libxmoc wrote:

 Look at `__gshared`. It's ugly.


I meant it to be ugly. The idea was to incentivize use of thread local storage 
to avoid hidden race conditions.

`__traits` was also meant to be ugly. The idea was these things are meant to be 
under-the-hood machinery that should be wrapped up in a nice library function 
implementation, and regular users shouldn't be seeing it.
Apr 12
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2026 12:27 AM, libxmoc wrote:

 Look at `__gshared`. It's ugly. Now look at `__traits`, `__vector`, 
 `__parameters`.


__vector was also meant to be hidden away, and the higher level abstractions in 
core.simd used instead.

__parameters should only be used in some advanced template metaprogramming.
Apr 12
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 4/12/26 01:27, Kapendev wrote:

 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.


 
 Breaking things just to be able to use `align` or `debug` as a variable 
 or enum name is not worth it. The solution: find better names.


I don't understand the premise. Why would that break anything?

Jonathan's original point was that contextual keywords are 
_undesirable_, not that they are _breaking_.

I.e., the contention is with "improvement", not "breaking".
Apr 12
parent Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 12 April 2026 at 11:03:59 UTC, Timon Gehr wrote:

 On 4/12/26 01:27, Kapendev wrote:

 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.


 
 Breaking things just to be able to use `align` or `debug` as a 
 variable or enum name is not worth it. The solution: find 
 better names.


 I don't understand the premise. Why would that break anything?

 Jonathan's original point was that contextual keywords are 
 _undesirable_, not that they are _breaking_.

 I.e., the contention is with "improvement", not "breaking".


I mentioned earlier that I can't comment about contextual 
keywords because I have no idea. If that works and it's easy to 
implement in D, then it's fine. My comment is about other ideas 
in general.
Apr 12
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
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:

 On Friday, April 10, 2026 4:37:54 PM Mountain Daylight Time 
 Katastic via Digitalmars-d wrote:

 Hello all, it's been awhile. I have a question. Does it make 
 'sense' that debug is a reserved keyword even when its inside 
 an enum?

 ```D
 enum loggingLevel {
   none = 0,
   debug, // Error: found `debug` when expecting `identifier`
   info,
   warning,
   error
 }
 ```

 Is there anywhere where that would actually clash?
 ```D
 void myFunction(loggingLevel l);
 myFunction(loggingLevel.debug);

 with(loggingLevel){
 myFunction(debug);
 }
 ```

 Is `debug` used anywhere outside of `version()` statements? 
 Would
 it explode templates or something?


 As a general rule, keywords in D are keywords no matter where 
 they are. They are not contextual. As such, you cannot use 
 them anywhere other than where the language uses that word. 
 There are of course downsides to that approach, but it's 
 simpler to process than contextual keywords, and it tends to 
 work better with stuff like error messages (since the keyword 
 then is essentially an anchor point in the grammar instead of 
 the compiler needing to figure which context you're trying to 
 use the keyword in when the context isn't well-formed due to 
 typos or whatnot).

 Obviously, that's annoying when you have a situation where a 
 keyword is the best identfier, but you can't use it, because 
 it's a keyword. However, the solution that's generally used in 
 D (and given in the official style guide) is that when you 
 need to use a keyword as an identifier, you apppend an 
 underscore to it:

 https://dlang.org/dstyle.html#naming_keywords

 So, you'd have `LoggingLevel.debug_` rather than 
 `LoggingLevel.debug`.

 A prime example of where this comes up in the standard library 
 is with `std.traits.FunctionAttribute`:

 https://dlang.org/phobos/std_traits.html#.FunctionAttribute

 The enum literally needs to list a bunch of keywords as its 
 values, and that's not legal, so trailing underscores have 
 been added to those keywords.


 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 

 keywords in specific positions.


That is quite an understatement. I’d go as far and say *most* 

and they’re all contextual.


 The "trailing underscore" convention is a concession that keeps 
 accumulating.



when they’d otherwise lead to errors: ` keyword`. Maybe D can use 

`#line`, those need to be the first non-whitespace character in 
their line, which cannot clash with a suffix. If you need such a 

as `debug$`.


 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.


The way to do this, IMO, is going over the list of keywords and 
identifying those that are both
* common English words, especially nouns, and
* rarely used.

For each:

1. Figure out if a common keyword would do. Rare cases may hit 
this, e.g. `body` → `do` is such a success story.

2. The remaining ones would be replaced by `__keyword`.

Here’s my take:

Obvious candidates
```
abstract    →   abstract
align       →  __align and kill `align` without parentheses
debug       →  __debug
deprecated  →  __deprecated
final       →   final
invariant   →  __invariant
pure        →   pure
version     →  __version
```

Those are English words that are used as keywords that are used 
in very specific contexts.
The most obvious candidates are `align`, `debug`, `export`, and 
`version`. `debug` especially warrants `__` because it breaks 
attributes. The average programmer very rarely uses `align` or 
`deprecated` and your code won’t become that more ugly when those 
need underscores. And while `version` is more common, it’s 
possibly also more common as a desired identifier. Similar is 
maybe `invariant`. You don’t use it that often that `__` would be 
too annoying, but in certain domains, having `invariant` as an 
identifier might be nice.

`abstract` and `final` simply don’t need to be keywords. Moving 
them to compiler-recognized UDAs allows them as identifiers and 
isn’t a big change.

I’m torn on:
```
export      →  __export
macro       →  remove it
package     →  __package
```

I’m not sure if `macro` is a highly desired identifier. `package` 
and `export` might be, but they’re visibility attributes and if 
we’re not targeting `private` and `public` maybe we should let 
them be, especially `package` because it takes an optional a 
parameter.
Apr 13
prev sibling parent libxmoc <libxmoc gmail.com> writes:
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. 

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.
Apr 11
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Use pascal case.
```d
/// Message severity level
enum Level
{
	/// Most verbose log level
	Verbose=0,
	/// ditto
	Finest=0,
	/// Deep debugging level, there's never enough of them
	Finer=1,
	/// Fine grained debugging
	Fine=2,
	/// Diagnostic information with technical details
	Debug=3,
	/// Reserve debug level when you suddenly need it
	Trace=4,
	/// High level event, e.g. user action
	Info=5,
	/// Noncritical problem
	Warn=6,
	/// Recoverable failure of current operation
	Error=7,
	/// Severe errors and other important information like program 
version
	Critical=8,
	/// Program crash
	Fatal=9,
	/// Filter only
	Mute=10
}

/**
Logging helper.
Examples:
---
private immutable Log=Logger(0);
Log.Debug("debug", number);
Log.Info("message");
Log.Warn("failure", errorCode);
Log.Error("system error", errorCode);
---
*/
struct Logger
{
	/// Logger name, can be filtered by `NameFilter`
	string Name;
	pure this(int, string name=__MODULE__){ Name=name; }
	immutable:
	private void Log3(Level level, in char[] message, long number, 
int line)
	{
		//pragma(inline, false);
		version(LogMute){}
		else Log(level,message,number,line,Name);
	}
	private void Log3(Level level, in MLog[] message, int line)
	{
		//pragma(inline, false);
		version(LogMute){}
		else Log2(level,message,line,Name);
	}
	/// Log message at specified level
	void Write(Level level, in char[] message=null, long number=0, 
int line=__LINE__)
	{
		if(level>=LevelFilter)Log3(level,message,number,line);
	}
	/// ditto
	void Write(Level level, scope const MLog[] message, int 
line=__LINE__)
	{
		if(level>=LevelFilter)Log3(level,message,line);
	}
	/// ditto
	alias Write opCall;
	/// Log debug message
	void Debug(in char[] message, long number=0, int line=__LINE__)
	{
		if(Level.Debug>=LevelFilter)Log3(Level.Debug,message,number,line);
	}
	/// ditto
	void Debug(scope const MLog[] message, int line=__LINE__)
	{
		if(Level.Debug>=LevelFilter)Log3(Level.Debug,message,line);
	}
	/// Log informational message
	void Info(in char[] message, long number=0, int line=__LINE__)
	{
		if(Level.Info>=LevelFilter)Log3(Level.Info,message,number,line);
	}
	/// Log warning message
	void Warn(in char[] message, long number=0, int line=__LINE__)
	{
		Log3(Level.Warn,message,number,line);
	}
	/// Log error message
	void Error(in char[] message, long number=0, int line=__LINE__)
	{
		Log3(Level.Error,message,number,line);
	}
}
```
Apr 11
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 11 April 2026 at 09:40:32 UTC, Kagamin wrote:

 Use pascal case.


The (optional) D style guide doesn't clearly forbid that, but I'm 
pretty sure it's against the spirit of it. Capitalized names are 
for types (or a symbol which could be a type). Enum members are 
values.

https://dlang.org/dstyle.html#naming_conventions

Also this interpretation is consistent with the *Eponymous 
Templates* part:


 types should be PascalCased and values should be camelCased
Apr 11
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Saturday, 11 April 2026 at 09:55:49 UTC, Nick Treleaven wrote:

 On Saturday, 11 April 2026 at 09:40:32 UTC, Kagamin wrote:

 Use pascal case.


 The (optional) D style guide doesn't clearly forbid that, but 
 I'm pretty sure it's against the spirit of it. Capitalized 
 names are for types (or a symbol which could be a type). Enum 
 members are values.


Minor correction: I’ve heard and observed the opposite: It should 
be PascalCase if it’s definitely (or at least usually) a type, 
not if it merely might be one.
Apr 13
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 13 April 2026 at 11:03:52 UTC, Quirin Schroll wrote:

 On Saturday, 11 April 2026 at 09:55:49 UTC, Nick Treleaven

 The (optional) D style guide doesn't clearly forbid that, but 
 I'm pretty sure it's against the spirit of it. Capitalized 
 names are for types (or a symbol which could be a type). Enum 
 members are values.


 Minor correction: I’ve heard and observed the opposite: It 
 should be PascalCase if it’s definitely (or at least usually) a 
 type, not if it merely might be one.


`std.meta` uses PascalCase for symbols that may be (but are not 
known to be) types, notably `AliasSeq`:
https://dlang.org/phobos/std_meta.html
Apr 13
parent Katastic <ckatko gmail.com> writes:
Wow, I wasn't expecting such a spirited discussion! There's a lot 
of interesting angles to this "ideal vs practical" issue. I'm 
learning a lot!

Thanks,
--Kat
Apr 13
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Friday, 10 April 2026 at 22:37:54 UTC, Katastic wrote:

 Hello all, it's been awhile. I have a question. Does it make 
 'sense' that debug is a reserved keyword even when its inside 
 an enum?

 ```D
 enum loggingLevel {
 	none = 0,
 	debug, // Error: found `debug` when expecting `identifier`
 	info,
 	warning,
 	error
 }
 ```


This is one of the main reasons why I use UPPER_SNAKE_CASE style 
for enum fields in all my code. Some other teams use PascalCase 
(upper camel-case). It is not just `debug`. `default` and 
`version` are other examples.
Apr 12
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
What you're suggesting is that `debug` be a context sensitive keyword.

D has some context sensitive keywords, such as:

```
extern (C) ...
pragma(msg,...)
__traits(isReg,...)
scope (exit)
```

But these are tightly constrained cases where they happen. If `debug` were 
contest sensitive, you can have problematic sequences like:
```
debug (foo(3));
```

Is `debug` a function call or a debug statement? It's ambiguous.

It's better to keep the ambiguous syntaxes to a minimum. Don't want to be like 
C/C++ where a correct parse requires a symbol table.
Apr 12
parent reply An Pham <home home.com> writes:
On Sunday, 12 April 2026 at 19:55:13 UTC, Walter Bright wrote:

 What you're suggesting is that `debug` be a context sensitive 
 keyword.

 D has some context sensitive keywords, such as:

 ```


D should convert some keywords into attribute instead. "debug" is 
one of them.
1. It is rarely used
2. It is attribute to a function or scope block

 debug .... ;
 debug {}

So, D should reduce keywords usage. Time to re-evaluate the list 
to make D less friction

Cheers
Apr 12
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/12/2026 4:12 PM, An Pham wrote:

 D should convert some keywords into attribute instead. "debug" is one of them.
 1. It is rarely used


I use `debug` all the time. BTW, `debug` was there a decade before the   syntax.


 2. It is attribute to a function or scope block
 
  debug .... ;
  debug {}
 
 So, D should reduce keywords usage. Time to re-evaluate the list to make D
less 
 friction


You can use `Debug` for user-defined things.
Apr 12
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Sunday, 12 April 2026 at 23:12:23 UTC, An Pham wrote:

 On Sunday, 12 April 2026 at 19:55:13 UTC, Walter Bright wrote:

 What you're suggesting is that `debug` be a context sensitive 
 keyword.

 D has some context sensitive keywords, such as:


 D should convert some keywords into attribute instead. "debug" 
 is one of them.
 1. It is rarely used
 2. It is attribute to a function or scope block

 ` debug .... ;`
 ` debug {}`

 So, D should reduce keywords usage. Time to re-evaluate the 
 list to make D less friction


Attributes are invalid in statement scope. I’d rather have 
`__debug`. `debug` isn’t an attribute, we shouldn’t pretend it is 
one.
Apr 13
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 10 April 2026 at 22:37:54 UTC, Katastic wrote:

 Hello all, it's been awhile. I have a question. Does it make 
 'sense' that debug is a reserved keyword even when its inside 
 an enum?


Yes I think.

D is designed so that it can be lexed separately from parsing, 
and parsed separately from compiling. Contextless keywords are 
needed for that feature to work.

`debug` needs to be a keyword, because it's needed to recognise 
code like `debug import std.stdio;`. If `debug` was considered 
just an identifier like any other, this wouldn't parse any more 
than `someName import std.stdio;`.

Now, there are some unnecessary keywords in D. The type names 
like `float`, `dchar` and `int` could be removed from keyword 
list as far as I see, since anywhere they can be used, an 
arbitrary type could be used in their place. They could be 
considered predefined types (just like `string`, `size_t` or 
`Throwable` for instance) with a normal non-keyword names. But 
`debug` is not among those reduntant keywords.
Apr 15