Version Algebra

[Walter Bright]

On 4/17/2026 1:08 AM, Dejan Lekic wrote:
> It becomes _much more_ complicated when you need to check for version, and 
> depending on version declare functions. D does not offer good solution for this 
> and that is where C preprocessor wins as we have to combine `version`s, enums, 
> static ifs in order to achieve things that are quite simple with C preprocessor.
> 
> Those who believe D is good for this should write a binding for a complex 
> library that supports all versions.

This is going back to version algebra.

I do understand how compelling having the algebra looks. But once you've been 
using it for a couple decades, across multiple diverse platforms, it starts to 
resemble a maze of twisty passages, all different.

The problems that arise are:

1. Losing track of what the result of the algebra is. It gets hard to figure out 
if a branch is "live" or "dead".

2. Adding a new system breaks the algebra in ways that are not immediately obvious.

3. Nobody knows what system the 'else' clause is meant for.

4. It becomes too easy to break system A when one is fixing system B.

5. Lots of twisty algebra makes it really hard to get things exactly right for 
system A. When coding for system A, one has to pick apart the parts that don't 
apply.

6. It is really unhappy when a contributor folds in support for a new system, 
and the result breaks the other working systems.


People don't believe me. Maybe 15 years ago, some people decided to use version 
algebra in druntime that relied on enums. Naturally, many bugs surfaced. This 
was dropped in my lap, and I removed all the algebra and replaced it with simple 
versions, and it has worked well since.

I occasionally go through druntime and make all the else clauses say "static 
assert(0, "unsupported OS");"

Homework assignment: pick a /usr/include .h file. Read the code and figure out 
which clauses are "live" without running cpp on it.