On 8/24/2023 1:51 PM, Richard (Rikki) Andrew Cattermole wrote:
> ```d
> void func() {
>      static assert(false);
> }
> ```
> 
> As long as you don't call func, it won't fire.

The static assert will fail at compile time. `assert(0)` will fail at run time.

On 8/24/2023 9:26 AM, John Colvin wrote:
> We have the ability to declare information (`enum`s and so on) & branch on it at compile time (`static if`), we have a package & module system to handle who can and does read that data. Beyond that, it's the author & build system’s problem imo.
> 
> I get the problem that `version` tries to solve, but I reckon if it didn’t already exist then it wouldn’t get added now.


At one point, druntime was largely converted to using enums and static if, to implement version algebra. It inevitably increased in complexity until nobody understood what was happening (due to circular imports).

It got dumped in my lap. I converted it all back to versions, and it's been trouble free ever since.

People can do as they like, but I prefer to stick with stupid simple version :-)

On Thursday, 24 August 2023 at 21:37:54 UTC, Walter Bright wrote:
> At one point, druntime was largely converted to using enums and static if, to implement version algebra. It inevitably increased in complexity until nobody understood what was happening (due to circular imports).
>
> It got dumped in my lap. I converted it all back to versions,

When was this?

> and it's been trouble free ever since.

It also tends to lag adoption on new platforms by a significant degree.

On 25/08/2023 9:26 AM, Walter Bright wrote:
> On 8/24/2023 1:51 PM, Richard (Rikki) Andrew Cattermole wrote:
>> ```d
>> void func() {
>>      static assert(false);
>> }
>> ```
>>
>> As long as you don't call func, it won't fire.
> 
> The static assert will fail at compile time. `assert(0)` will fail at run time.
> 

Currently yes. I proposed a change where it requires some form of usage or would have contributed towards some usage. Basically a deferment of failing.

On 8/24/2023 11:04 AM, Adam D Ruppe wrote:
> But, I'd point out that this kind of thing is even worse than not having the `else static assert(0)` branch at all. Suppose you wrote it like this in the first place:
> 
> ```
> version(Windows)
>    enum x = 8;
> version(linux)
>    enum x = 8;
> 
> // somewhere else
> 
> version(Windows)
>    enum y = 9;
> version(linux)
>    enum y = 7;
> ```
> 
> You port it to AdrOS.
> 
> ```
> import that;
> void main() {
>     auto thing = x;
> }
> ```
> 
> You now get a nice error: undefined identifier "x". *as you use it*, the compiler tells you it is missing and you know to go fix it. Then later, when you use y, you again get undefined identifier and you go back and add it. It is incrementally ported - always compiling the core, with more advanced test cases failing until you fill in those features.

If you want to do it that way, that's ok. I just want to head off the commonplace use of defaults. I also like, when I've ported to a new OS, knowing where all the OS specific tweaks need to go, up front. Getting an "undefined x" doesn't tell me where the x needs to be defined.

But your method is still workable.

On 8/24/2023 2:51 PM, Adam D Ruppe wrote:
> On Thursday, 24 August 2023 at 21:37:54 UTC, Walter Bright wrote:
>> At one point, druntime was largely converted to using enums and static if, to implement version algebra. It inevitably increased in complexity until nobody understood what was happening (due to circular imports).
>>
>> It got dumped in my lap. I converted it all back to versions,
> 
> When was this?

Beats me. Long time ago. I think stdc.stdio was one of the afflicted, so you can check the history on that.


>> and it's been trouble free ever since.
> It also tends to lag adoption on new platforms by a significant degree.

Having done ports to new OS's myself, that hasn't been a significant impediment.

On Tuesday, 22 August 2023 at 17:57:52 UTC, Paul Backus wrote:
> ...
> There's a 1992 article on writing portable C programs that comes to similar conclusions:
>
> https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf

Love this part: ..."Many of the problems we discuss stem from the 'never mind good,we want it nextweek' approachto software"...

I thought it was talking or related where I work until I read the year 1992 on the footnote. =]

Matheus.