I don't have links, it was a long time ago, but there was a time when someone introduced enums to druntime modules and used them with non-trivial static if expressions. People started extending this, and it soon became quite a tangle of some static ifs depending on other static ifs and the declarations of the enums became embedded in static ifs and then, inevitably, circular imports came into play.

Then, the whole thing reached a point where nobody could figure out whether particular static ifs were being triggered or not. The problem got dumped in my lap, and I yanked out all the static if's and replaced them with trivial logic.

In getting ImportC to work with system .h files, written by the best C experts on the planet, I've been re-acquainted with #ifdef hell.

I used to write #ifdef hell myself. It's very seductive.

So, yes, you can use static if and enums to implement version hell. But not in any official Dlang repositories.

On 5/21/2023 7:01 PM, Hipreme wrote:
> Right now I've come to understand that using feature based versions instead of real versions really makes a lot of difference. But as Guillaume pointed out, there is still this other problem of defining a feature based on multiple platforms and this solution doesn't really make one write a lot less, so I still find this solution lacking for our problem which makes me wonder if there really exists a good solution for that.

version(linux)         enum ExtraFunctionality = true;
else version(OSX)      enum ExtraFunctionality = true;
else version(Windows)  enum ExtraFunctionality = false;
else static assert(0, "system not accounted for");

The static assert is there because a very common failure of #ifdef hell is to have defaults that botch things up when a new version is added.

This happens sometimes in the druntime imports, when I discover them I add the static assert.

There are still other ways to do it:

```
import extra;
void foo()
{
    extraFunctionality();
}
```

```
module extra;

void extraFunctionality()
{
  version(linux)         doit();
  else version(OSX)      doit();
  else version(Windows)  { }
  else static assert(0, "system not accounted for");
}
```

Another way is to write a "personality module" for each operating system, and then import the right one:

```
module extra;
version (linux) import extraLinux;
else version (OSX) import extraOSX;
... and so on ...
```

Personally, I like to make the core code version-independent and OS-independent and hide the variances in separate modules. Isn't foo() clean looking?

```
version(linux)         enum ExtraFunctionality = true;
else version(OSX)      enum ExtraFunctionality = true;
else version(Windows)  enum ExtraFunctionality = false;
else static assert(0, "system not accounted for");
```

(forgot to use Markdown! Oops!)

On Monday, 22 May 2023 at 08:21:50 UTC, Walter Bright wrote:

>
> Personally, I like to make the core code version-independent and OS-independent and hide the variances in separate modules. Isn't foo() clean looking?

I sense echoes of the infamous "Clean Code" debate. Why can't we just let the programmer decide whether to put the versions inline or to hide them behind an abstraction?

On 22/05/2023 8:21 PM, Walter Bright wrote:
> The static assert is there because a very common failure of #ifdef hell is to have defaults that botch things up when a new version is added.

If you want to be principled about it, one way to consider it is that not having an else branch (even if empty) should be an error. Because you clearly didn't think about the multiplicative issues of the versions.

Regardless, or'ing isn't the issue, its when you and versions that you get an explosion of multiplicative issues.

An option could be to use comma instead of ``||`` to handle or'ing. That way people won't be so tempted to "just extend it" to other operators like and.

On Monday, 22 May 2023 at 08:21:50 UTC, Walter Bright wrote:
> On 5/21/2023 7:01 PM, Hipreme wrote:
>> Right now I've come to understand that using feature based versions instead of real versions really makes a lot of difference. But as Guillaume pointed out, there is still this other problem of defining a feature based on multiple platforms and this solution doesn't really make one write a lot less, so I still find this solution lacking for our problem which makes me wonder if there really exists a good solution for that.
>
> version(linux)         enum ExtraFunctionality = true;
> else version(OSX)      enum ExtraFunctionality = true;
> else version(Windows)  enum ExtraFunctionality = false;
> else static assert(0, "system not accounted for");
>
> The static assert is there because a very common failure of #ifdef hell is to have defaults that botch things up when a new version is added.
>
> This happens sometimes in the druntime imports, when I discover them I add the static assert.
>
> There are still other ways to do it:
>
> ```
> import extra;
> void foo()
> {
>     extraFunctionality();
> }
> ```
>
> ```
> module extra;
>
> void extraFunctionality()
> {
>   version(linux)         doit();
>   else version(OSX)      doit();
>   else version(Windows)  { }
>   else static assert(0, "system not accounted for");
> }
> ```
>
> Another way is to write a "personality module" for each operating system, and then import the right one:
>
> ```
> module extra;
> version (linux) import extraLinux;
> else version (OSX) import extraOSX;
> ... and so on ...
> ```
>
> Personally, I like to make the core code version-independent and OS-independent and hide the variances in separate modules. Isn't foo() clean looking?

Yes, I do understand. Although I prefer `static assert` to not be used, but the runtime `assert`. I have done a port of the druntime and the `static assert` usage really is a pain since there is just a plain lot of code which is not used by me, but only for its existence, it causes a compilation error.


I think the feature based is cleaner to read most of the time (and scalable), I have done a good refactor in a lot of D code already using that, and IMO, it did done wonders into making the code intention crystal clear even for non maintainers. This is a thing which I've come to understand the decision of not allowing boolean operators on `version`. Maybe if there was a construct for allowing **only version declaration** with boolean operators like:
`version RelaxedSystems = version(Windows && linux && !OSX)` (it would not be global as the `version` is right now. i.e: not allow this syntax to be used standalone.

So, the operators aren't really the hell that causes the `#ifdef` hell as you said. The problem are 2:

1: They being defined over all files. While trying to port newlibc, I've come to find a type to be defined over 6 files. Which meant I really went jumping from a file to file until I was able to find how the type were defined. This is a real problem since the type is not self contained so it is super hard to look. How to solve that: D has solved! Just make the `version =` not spam into multiple files.

2: Operators: they don't really make sense when other people are looking into them, which is solved by having the feature named, so, enforcing the naming to use the operators could be a problem solving in the syntax. Since they aren't global, they are painful to keep writing all the time the same thing (I've tried doing that on directx-d binding and omg, I basically got a 8 line headers in almost all files, sure, it is easier to read than C, but it was painful writing them).