Glad hear it's working for you!
On Friday, 6 January 2017 at 10:25:26 UTC, Claude wrote:
So I had a stream of:
version (Win32)
enum bool WindowsSupported = true;
else
enum bool WindowsSupported = false;
version (Win64)
enum bool WindowsSupported = true; //Ooops
else
enum bool WindowsSupported = false; //Ooops
These can be condensed to:
version(Win32)
enum bool WindowsSupported = true;
else version(Win64)
enum bool WindowsSupported = true;
else
enum bool WindowsSupported = false;
Or even better, since it doesn't appear you need to distinguish
between 32-bit & 64-bit:
version(Windows)
enum bool WindowsSupported = true;
else
enum bool WindowsSupported = false;
It turned out to be not so readable (even when using a "string
mixin" to make the code tighter), and I cannot define twice an
enum without using "static if", which was a deal-breaker. Also
the conciseness of the versions for the D compilers (only 4:
DMD, GDC, LDC and SDC), as well as the different OS versions
made the code a lot tighter than the C version.
For me, the readability is no issue. I would put that block above
in a single module (which I like to call config.d) and then
import it where I need it. This actually is a lot cleaner for the
corner cases where version breaks down (see below).
So I just dropped the enum definition thing and just used
"version" as it was designed to be used:
version (Win32)
version = WindowsSupported;
else version (Win64)
version = WindowsSupported;
else etc...
version(Windows) { }
That little experience showed that using version as it is
designed currently is enough to elegantly cover my needs. And
it seemed to scale well.
Also I think it may force developers to handle all version
specific stuff into one specific module and define your own
version identifiers to list features from compiler, OS, target
architecture version identifiers; which is a good coding
practice anyway.
Yes, it works quite well for most use cases and should generally
be preferred. I disagree that it scales, though. At some point (a
point that is highly project-dependent), it breaks down,
requiring either very large modules or duplicated versions across
multiple modules.
My position is that I will always choose version blocks first,
but if I find myself in a situation where I have to choose
between duplicating version statements (e.g. version(A)
{version=AorB; version=AorC;}) across multiple modules and
restructuring my code to accommodate versioning, I much prefer to
use the enum alternative as an escape hatch.
