https://github.com/dlang/dmd/pull/16280/files

Sometimes if you stare at code long enough, its underlying simplicity emerges.

On Saturday, 2 March 2024 at 20:27:59 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/16280/files
>
> Sometimes if you stare at code long enough, its underlying simplicity emerges.

Why would you use a bunch of daisy chained conditionals instead of a switch?

    with (Id) with (CppOperator) switch (id)
    {
        case _cast  : return Cast;
        case assign : return Assign;
        case eq     : return Eq;

etc..

IMO that is clearer, and likely faster, unless the compiler is smart enough to transform the daisy chain into a switch? What's the threshold on DMD for using a jump table? I think it's 3 or 4 on LDC.

On Sunday, 3 March 2024 at 00:44:44 UTC, claptrap wrote:
> Why would you use a bunch of daisy chained conditionals instead of a switch?
>
>     with (Id) with (CppOperator) switch (id)
>     {
>         case _cast  : return Cast;
>         case assign : return Assign;
>         case eq     : return Eq;
>
> etc..
>
> IMO that is clearer, and likely faster, unless the compiler is smart enough to transform the daisy chain into a switch? What's the threshold on DMD for using a jump table? I think it's 3 or 4 on LDC.

While Id looks like an enum, it is actually a struct with a bunch of static member variables, and the type of those static variables is "class Identifier." You can't switch on a class instance.

On Saturday, 2 March 2024 at 20:27:59 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/16280/files
>
> Sometimes if you stare at code long enough, its underlying simplicity emerges.

I don't see how that is simpler than the original (given the lazily initialized dynamic array is replaced with a static one and the loop is replaced with an FP equivalent).

On 3/2/2024 9:48 PM, Max Samukha wrote:
> I don't see how that is simpler than the original (given the lazily initialized dynamic array is replaced with a static one and the loop is replaced with an FP equivalent).

1. no need to manually verify that the array is in the same order as the enum.

2. no variables are declared

3. there's no concern about thread safety with the static variable initialization

4. no cast conversion, which has to be checked manually

On Sunday, 3 March 2024 at 07:30:53 UTC, Walter Bright wrote:
> 1. no need to manually verify that the array is in the same order as the enum.

Fair.

>
> 2. no variables are declared

True.

>
> 3. there's no concern about thread safety with the static variable initialization

The array doesn't need to be lazily initialized (unless I miss some important detail).

>
> 4. no cast conversion, which has to be checked manually

Right.

I could list a number of random points in favor of the original.