Good examples of version() algebra in real code

[Walter Bright]

On 5/22/2023 4:06 AM, Hipreme wrote:
> 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.

Runtime assert doesn't work at module scope. Also, it's usually better to catch 
porting errors at compile time, rather than after the code was shipped.


> 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.

As I mentioned elsewhere, that goes wrong, too.


> 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.

Yup. D does not "import" versions from other modules. This was another crucial 
design decision that has paid off handsomely. How miserable it is in C to figure 
out where a #define is coming from in the typical rat's nests of #include's, or 
even if it is #define'd at all.


> 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.

Most people read code a hundred times more than they write code, so being a bit 
verbose to improve reading is a worthwhile tradeoff.


 > 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).

The technique, as I mentioned in the upstream post, is to have the feature 
versions in one file, have `extraFunctionality()` defined as doing something or 
a noop in that file, and just call `extraFunctionality()` elsewhere.

I should write an article about this.