> The fact that everyone has their own work-around, and everyone has a > DIFFERENT work around is hard evidence that version() is > insufficient, and the current design is making D code WORSE. > Even Walter describes and supports the work-arounds to use > in his poses from years ago.
Seems I'm joining in the middle of a debate, sorry if I say anything already answered in a previous post. I may be in error, if so likely ignore this. This seems to be more a talk about inconsistent use of version (and redundancies). I'll add my two cents. It seems to me that OS and architecture specific modifications (that would make use of version()) should be in it's own file, perhaps something like 'arch_specific.d' and 'os_specific.d'. That way any unique and domain/system specific inconsistencies/issues can be handled in one place. Like Windows, Posix, x86_64 code, etc. Making multiple source files to deal with specific OS's or other related issues seems like the whole issue with code duplication (Change one, gotta change it everywhere else too). So having a 'os_windows.d' and 'os_posix.d' and a 'os_freebsd.d' and whatever other possible combinations just seems to in the long run breed problems rather than solving them, especially if they are minor differences between them. The only time you should include version specific in your sources, is when the differences are only in one spot (anywhere in the code), only one source file, or compile time sources and pre-compiled modules cannot work together. That goes down to compiler implementation. Likely you'll be compiling from sources so that ceases to be the issue. Version, mixins, static if's and aliases effectively remove the need for a preprocessor, doing the same job in a more controlled way that wasn't ugly and doesn't require extra passes through the source. But excessively using any and all of these (or misusing) can make code appear as bad as anything in a C's .h file. D is not a religion; But everyone (well almost) understands the need for consistency, code cleanliness and separation of Architecture & OS specific code. So barring the most trivial uses of version (or only found in one spot ever) guidelines and recommendations should be put down. 'The D Programming Language' book Andrei published has maybe a whole Page on version() total. The exact guidelines to follow may not matter so much, so long as it's clean, simple to follow and remember, and makes enough sense that everyone tries to adopt it. I'm sure if Walter or Andrei put an article, coding standards, or said 'Just do it this way', everyone would likely follow suit; Mostly since it gives you a direction and not leaving you to make up something on your own or worse follow previous conventions that used a pre-processor in C or C++. Hope I haven't rambled too much.
