I think this could be a useful test case for a lint-like tool, and perhaps not DMD itself. But I'm putting it in bugzilla just so I don't ever forget that I ran into it: enum paFloat32 = 0x0000_0001; enum paInt32 = 0x0000_0002; enum paInt24 = 0x0000_0004; enum paInt16 = 0x0000_0008; enum paInt8 = 0x0000_00100; enum paUInt8 = 0x0000_0020; enum paCustomFormat = 0x0001_0000; enum paNonInterleaved = 0x8000_0000; Hmm.. all seems fine. Except line 5, there's an extra zero at the end! The integer value of paInt8 is 256 instead of 16. I've had this bug manifest itself while translating a C header file. I don't really know how it got there, I know I've added the underscores after HTOD made a pass over the C header, and that's where I screwed up and must have added another zero. There's probably not much to do about this. It's still a valid hex literal, it doesn't overflow, and the underscores are purely conventional and not something the compiler forces you to do every 4 spaces. But it caused a bug and it's worth mentioning. Sorry if this doesn't belong here..
*correction* I just saw my git commit, the code was: enum PaSampleFormat paFloat32 = 0x00000001; -enum PaSampleFormat paInt32 = 0x00000002; -enum PaSampleFormat paInt24 = 0x00000004; -enum PaSampleFormat paInt16 = 0x00000008; -enum PaSampleFormat paInt8 = 0x000000010; -enum PaSampleFormat paUInt8 = 0x00000020; -enum PaSampleFormat paCustomFormat = 0x00010000; -enum PaSampleFormat paNonInterleaved = 0x80000000; So I actually spotted the bug *after* I added the underscores. Heh, I guess this isn't an enhancement request but just a heads up for using underscores, it's a great feature. I'm closing this down.