No need for version expression is a lie

[Jonathan M Davis]

On Monday, August 21, 2023 12:46:47 PM MDT Basile B. via Digitalmars-d wrote:
> On Monday, 21 August 2023 at 18:01:20 UTC, Walter Bright wrote:
> > On 8/21/2023 9:26 AM, Basile B. wrote:
> >> On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
> >>> On 8/21/2023 8:39 AM, Basile B. wrote:
> >>>> Like you pretend that `enum DEFAULTS` is not a workaround
> >>>> the limitations.
> >>>
> >>> I would not use the DEFAULTS, but would spell it out for each
> >>> system. Then it looks like a table, with rows and columns,
> >>> and makes it easy to see which setting is for which system.
> >>
> >> you have to read top down to see what DEFAULTS do.
> >
> > That's why I wouldn't use the DEFAULTS approach. Just make a
> > table.
>
> However that approach was used. It really looks like an
> alternative to a version OrOr. There are plenty of other examples
> in drutime sources.
>
> Sure at some point there is also the problem of the unix
> standards...Every distribution can choose its own value for the
> flag of this func or that one...which creates complexity in C
> `define`s, but should not in D. There is a problem that is not
> solved.

The way that version statements try to enforce a lack of boolean logic
reflects the way that Walter believes (rightly or wrongly) that versioning
code should work based on his experience, but it does not actually prevent
you from writing code that uses boolean logic for versioning. It just makes
it harder, and given how much most programmers hate code duplication
(whereas the way that Walter wants versioning done typically introduces
quite a lot of code duplication, even if it's for a good cause), plenty of D
programmers routinely work around how version works in order to introduce
boolean logic into how they version code. D runtime is not immune to this
any more than any other D code, particularly since Walter wrote very little
of it. If anything, it probably follows what Walter wants more than most D
code, because it's official D stuff, but the way that Walter wants
versioning done (while arguably a good idea) strongly goes against how
programmers typically function, so it's pretty natural that stuff like this
would creep into druntime.

Arguably, stuff like this should be removed from druntime to reflect how
Walter wants versioning to be done, but clearly, no one who has spent much
time working on druntime has felt strongly enough about it to spend the time
to fix the problem, and whoever reviewed the code in question when it was
first introduced didn't insist on it being fixed.

Utimately, the fact that people routinely try to work around how version
statements work in D doesn't really say anything about whether the reasons
for them working the way that they do are good or not. It just shows that
(for better or worse) most programmers haven't been brought around to
Walter's way of thinking with regards to versioning. In reality, I expect
that most of the programmers versioning code in D aren't even aware of why
it works the way that it works. They just want to version code the way that
comes naturally to them, so they end up fighting how version works rather
than adjusting how they function to match.

Personally, I think that Walter is probably right about how versioning
should be done, but at the same time, I find it irritating, because it
introduces so much code duplication. The code duplication is there to reduce
the complexity and reduce the risk of other kinds of problems that typically
come with having different versions of the same code, so it is arguably a
good a tradeoff, but it often just feels wrong even if it isn't.

That being said, fortunately, most D code doesn't have to worry about
version statements much, because druntime hides most of that mess. There are
other libraries that wrap C code and/or are more low-level in nature which
have to do a fair bit of versioning with code, but most D code is able to be
version-agnostic, which fortunately keeps the issues with how how version
statements work to a minimum.

- Jonathan M Davis