On Wednesday, 31 July 2024 at 06:11:15 UTC, Walter Bright wrote:

> version (x86_64)
> {
>     enum FOO
>     {
>        A = 5,
>        B = 6,
>        C = 7,
>     }
> }
> else version (AArch64)
> {
>    enum FOO
>    {
>        A = 5,
>        B = 6,
>        C = 17,
>    }
> }
> else
>     static assert(0);
> ```
>
> Ah, doesn't that look nicer?

It's been said maybe a billion times why this solution rarely works in the read world. And the arguments have been dismissed in the classic D way.

On 01/08/2024 4:04 AM, Max Samukha wrote:
> On Wednesday, 31 July 2024 at 06:11:15 UTC, Walter Bright wrote:
> 
>> version (x86_64)
>> {
>>     enum FOO
>>     {
>>        A = 5,
>>        B = 6,
>>        C = 7,
>>     }
>> }
>> else version (AArch64)
>> {
>>    enum FOO
>>    {
>>        A = 5,
>>        B = 6,
>>        C = 17,
>>    }
>> }
>> else
>>     static assert(0);
>> ```
>>
>> Ah, doesn't that look nicer?
> 
> It's been said maybe a billion times why this solution rarely works in the read world. And the arguments have been dismissed in the classic D way.

Yeah not supporting this, just doesn't fit D anymore.

Too many people try it, which shows that it is clearly good language design.

It helps to fulfill peoples ideas, so an easy win to me.

On 7/31/2024 2:23 AM, IchorDev wrote:
> your suggestion forsakes the DRY principle.

Indeed, it does. Consider the evolution of expertise:

1. novice - follows the rules because he's told to

2. master - follows the rules because he understands the point of the rules

3. guru - violates the rules because he understands when the rules don't apply

BTW, your example looks fine as it is!

On 7/31/2024 10:51 AM, Richard (Rikki) Andrew Cattermole wrote:
> Too many people try it, which shows that it is clearly good language design.

People try all kinds of things in programming, eventually they evolve towards Best Practices.

On 01/08/2024 7:08 AM, Walter Bright wrote:
> On 7/31/2024 10:51 AM, Richard (Rikki) Andrew Cattermole wrote:
>> Too many people try it, which shows that it is clearly good language design.
> 
> People try all kinds of things in programming, eventually they evolve towards Best Practices.

Luckily we have Dscanner, so if it turns out a pattern gets too complex and therefore is not best practice, we can throw a warning at it without breaking code!

Which severely diminishes any possible objections.

On 7/31/2024 9:04 AM, Max Samukha wrote:
> It's been said maybe a billion times why this solution rarely works in the read world.
I know, it comes up regularly.

A classic case is the antecedent where a list of operating system enum values changes with each platform.

I've had the dubious pleasure of having to fix the equivalent for struct fields that vary by operating system, and were wrong because it's hard to compare a mess of conditional compilation with the operating system spec which does not have conditionals in it.

Let's look at the original again:

```
enum FOO {
    A = 5,
    B = 6,
version (x86_64) {
    C = 7,
} else version (AArch64) {
    C = 17,
} else {
    static assert(0);
}
    E = 9, // fixed that!
}
```

The example does follow best practice by adding the static assert for an unanticipated operating system. Now, let's add a G for AArch64:

```
enum FOO {
    A = 5,
    B = 6,
version (x86_64) {
    C = 7,
} else version (AArch64) {
    C = 17,
} else {
    static assert(0);
}
    E = 9,
    G = 10,
}
```

Does x86_64 have a G, or not? Is the programmer going to check each supported system for G? No, they're not. Are they going to wrap it in its own version declaration? Nope. (Even if they do, it runs afoul of what to do about the else clause.) I see it again and again. I fix them again and again. Sometimes they are never caught at all.

One could put G in the AArch64 block, but then it is out of order, making it hard to check them against the operating system spec which will be in order.

But if the operating systems are in separate declarations, this is not an issue. The person adding G to x86_64 doesn't need to check operating systems he's not familiar with.

Getting the enum values wrong results in really hard to debug failures.

I know you don't find this convincing.

On Wednesday, 31 July 2024 at 19:08:13 UTC, Walter Bright wrote:
> On 7/31/2024 10:51 AM, Richard (Rikki) Andrew Cattermole wrote:
>> Too many people try it, which shows that it is clearly good language design.
>
> People try all kinds of things in programming, eventually they evolve towards Best Practices.

?

Someone who starts at haskell will end up very different then someone who starts with c; to say nothing of different kinds of problems.

No. If you ask 5 80 year old programmers youll get 5 different answers for whats a "best practice" we all wont "evolve" to the same answers for the foreseeable future.

On Wednesday, 31 July 2024 at 06:11:15 UTC, Walter Bright wrote:
> This comes up from time to time.
>
> ```
> enum FOO {
>    A = 5,
>    B = 6,
> version (x86_64) {
>    C = 7,
> } else version (AArch64) {
>    C = 17,
> } else {
>    static assert(0);
> }
>    version E = 9,
> }
> ```
>
> I've seen this forever in C. It just makes my brain bleed. Here's the D way:
>
> ```
> version (x86_64)
> {
>     enum FOO
>     {
>        A = 5,
>        B = 6,
>        C = 7,
>     }
> }
> else version (AArch64)
> {
>    enum FOO
>    {
>        A = 5,
>        B = 6,
>        C = 17,
>    }
> }
> else
>     static assert(0);
> ```
>

The clean way is using "mixin" & "import"

foo_windows.enum  file
enum FOO
{
  A = 5,
  B = 6,
  C = 7,
}

foo_aarch64.enum  file
enum FOO
{
  A = 5,
  B = 6,
  C = 17,
}

main.d  file
module m;

version(Windows)
    mixin(import("foo_windows.enum"));
else version(AArch64)
    mixin(import("foo_aarch64.enum"));
else
    static assert(0);

version(Windows)
    static assert(FOO.C == 7);
else version(AArch64)
    static assert(FOO.C == 17);

void main()
{
}

build with  dmd.exe -J="directory of those enum files..." main.d