November 22, 2003
Hi

Currently the Versioning system is starting to get as messy as it's C counterpart it is supposed to replace (and improve uppon). The problem lies in naming conventions, and what versions are defined by various compilers (just two yeat, but there's no point assuming there won't be more). This might not be a big problem now as there is only one major compiler defining the standard, but as different people start writing new compilers with their own opinions on what to name things, it will get messy.

A suggestion how to organize things:
Create a "subgroup" for important system/compiler specific versions.

These subrgoups can be exclusive, eg only one of the versions in that group
might be set:
system.compiler.DigitalMars //code is compiled by only one compiler
system.endian.little        //a system have either little or big endian
system.platform.linux       //we run (compile to run) on one platform

This also makes it possible to make an "version( .. ) .. else" statement, but
this goes on the "might be handy" list :)

Other groups might have many versions set:
system.features.InlineASM
system.features.ASM_MMX
system.features.ASM_SSE
.etc

How to differ exlusive groups from non-exclusive ones.. well.. we'll just have to trust the specification I guess.

The current status is that "Others will be added as they make sense and new implementations appear" and says nothing of what they will be called. Besides new compilers will have it own set of versions set, making it a nightmare for people that write code that can compile on loads of platforms/compiler combinations. (This is what I call the "problem" with C. There's at least 5 different ways of checking (all exclusive for its compiler/platform combination) of just checking for little/big endian).

- Marvin


November 23, 2003
You raise some good issues. Some of them are addressed by std.compiler, and std.system.